Re: [PHP-DEV] RE: Announcing RFC 'Anonymous Catches'
On Wed, Jun 26, 2013 at 7:54 AM, Joost Koehoorn wrote: > On 26 juni 2013 at 08:35:59, Michael Wallner (m...@php.net) wrote: > On 25 June 2013 22:23, Johannes Schlüter wrote: > > On Tue, 2013-06-25 at 13:19 -0700, Stas Malyshev wrote: > >> Hi! > >> > >> > If I'm to understand this RFC correctly, it is nothing more than a > >> > random suggestion someone posed in the form of a tweet and the author > is > >> > saying why not add it since it's not hard to implement. So in > summation > >> > >> Well, here we go - this is why not add it, because it makes working > with > >> such code harder without actually benefiting anybody. > > > > +1 > > > > Right now I set a breakpoint in my editor and look at an exception even > > if it is not used, in future I'd have to change the code for that. > > Hrm, this is a very good point! > > >> > So this entire discussion can be summed up nicely with "Let's make > the > >> > variable optional because... why not?". > >> > >> "Why not" is usually not a very good principle of language design, IMO. > > > Nothing more to add. > > -- > Regards, > Mike > This is a little pathetic. Someone sums it up to "Why not", which is not > the case, we have grounded arguments for this, Not really. The arguments posed so far are "I want to get rid of the variable because I'm not using the variable", which isn't a justification. It's just a circular argument that can go both ways. You can get what you want and still not get rid of the variable. The difference is if you get rid of it you make code harder to debug and thus promote worse practices than already exist in PHP. > and then all agree that "Why not" is not a reason to add something. Surely > it isn't. > > You mention bad coding practices. Sure, we should avoid them. Unused > variables is a bad coding practice. So, we should avoid them. Luckily, it's > easy to avoid them with catch-statements, because we can simply make the > variable optional. > You can avoid bad practices by allowing the practice to exist where it does not already? Surely this doesn't make sense when you re-read it out loud. > > I recently wrote a CLI tool in C# to import data from Team Foundation > Server. During an update, I try to download every new commits from where I > last stopped (so, from commit "latest+1"). That fails with a > ChangesetNotFoundException when no such commit exists, fair enough. I > cannot test beforehand whether that exception will be thrown (that would > mean I needed two calls to the server, now it's in one round) so it's > totally expected. I'm doing this for 100.000 files and I don't want to do > anything with the exception, it's nothing more than an indication that > we're already up-to-date for that file. Done. In PHP I would have an unused > variable, which trips up my static analysis tool that keeps warning me > about the bad coding practice of having an unused variable. I agree, it's > bad to have that variable defined but PHP won't let me get rid of it. > Another reason for people to bitch about PHP. > So basically the only argument you have here is that you want to change PHP to get your IDE to stop complaining about unused variables? I'm not even going to justify the "Another reason for people to bitch about PHP" since that conversation really doesn't even belong in Internals discussion. > > Luckily, we can do something about it, and it happens to be easy. > We can also just as easily ignore the variable in user space. Doing so will at least leave the user with a means to consider why they're catching Exceptions that might not be handling well. I understand you feel you have no reason to touch the exception variable, but this is not a good enough reason to get rid of it. Anytime you get rid of information that's available to user space that can be used to debug code you are losing something valuable. It may not be valuable to you, but this is the exception and not the rule. We should not be throwing this information away.
Re: [PHP-DEV] RE: Announcing RFC 'Anonymous Catches'
On 26 juni 2013 at 08:35:59, Michael Wallner (m...@php.net) wrote: On 25 June 2013 22:23, Johannes Schlüter wrote: > On Tue, 2013-06-25 at 13:19 -0700, Stas Malyshev wrote: >> Hi! >> >> > If I'm to understand this RFC correctly, it is nothing more than a >> > random suggestion someone posed in the form of a tweet and the author is >> > saying why not add it since it's not hard to implement. So in summation >> >> Well, here we go - this is why not add it, because it makes working with >> such code harder without actually benefiting anybody. > > +1 > > Right now I set a breakpoint in my editor and look at an exception even > if it is not used, in future I'd have to change the code for that. Hrm, this is a very good point! >> > So this entire discussion can be summed up nicely with "Let's make the >> > variable optional because... why not?". >> >> "Why not" is usually not a very good principle of language design, IMO. Nothing more to add. -- Regards, Mike This is a little pathetic. Someone sums it up to "Why not", which is not the case, we have grounded arguments for this, and then all agree that "Why not" is not a reason to add something. Surely it isn't. You mention bad coding practices. Sure, we should avoid them. Unused variables is a bad coding practice. So, we should avoid them. Luckily, it's easy to avoid them with catch-statements, because we can simply make the variable optional. I recently wrote a CLI tool in C# to import data from Team Foundation Server. During an update, I try to download every new commits from where I last stopped (so, from commit "latest+1"). That fails with a ChangesetNotFoundException when no such commit exists, fair enough. I cannot test beforehand whether that exception will be thrown (that would mean I needed two calls to the server, now it's in one round) so it's totally expected. I'm doing this for 100.000 files and I don't want to do anything with the exception, it's nothing more than an indication that we're already up-to-date for that file. Done. In PHP I would have an unused variable, which trips up my static analysis tool that keeps warning me about the bad coding practice of having an unused variable. I agree, it's bad to have that variable defined but PHP won't let me get rid of it. Another reason for people to bitch about PHP. Luckily, we can do something about it, and it happens to be easy. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RE: Announcing RFC 'Anonymous Catches'
>> If you have an exception like `BadCredentialsException` and throw it >> during authentication if the user has entered wrong login data, than >> you have such a situation right? >> But do you need any further information? No - in the catch block it may >> be enough to create a message for the user saying: "wrong username or >> password". > > I believe that the example you provided, the one with > 'BadCredentialsException', is a good example of a bad design and usage > of exceptions, at least from my point of view. > > The fact that frameworks like Symfony2, Zend Framework or other php > libraries/frameworks (ab)use the exceptions it doesn't mean that it's > a good thing or you should have exceptions for everything. Alright... all bigger frameworks have a bad design... > The provided example could just as well return false; for the login > function and that's it, no? What if a false login could have different reasons? And these reasons could be dynamic because other users may add event listeners and add additional "exceptional cases"? `false` cannot contain this information. > Exceptions should be used for exceptional cases where the application > can't recover automatically from them. > They are, even as their name suggests, exceptional cases, while a bad > credential for a user login is not :) I think you are confusing "exception" with "error". It is a point of view wheather a case is exceptional or not. In my opinion bad credentials are an exception because the normal flow is a successful login. Best regards -- Christian Stoller LEONEX Internet GmbH
Re: [PHP-DEV] RE: Announcing RFC 'Anonymous Catches'
On Wed, Jun 26, 2013 at 8:31 AM, Christian Stoller wrote: >>> But I think it looks a bit cleaner if the variable could be omitted, >>> if it's not needed ;-) >> >> I don't think we need to change the language because Netbeans can't >> figure out how catch blocks work. > > The Netbeans thing was just an example/addition. > >> It's not used by you - which btw is usually not a good idea - if you've >> got an exception, you usually should somehow react to it - at least log >> it or something, that's what the exceptions are for, if the situation >> does not require special handling it shouldn't be an exception. But it > > If you have an exception like `BadCredentialsException` and throw it during > authentication if the user has entered wrong login data, than you have such a > situation right? > But do you need any further information? No - in the catch block it may be > enough to create a message for the user saying: "wrong username or password". > > Maybe you only use generic exceptions like `RuntimeException`. This can be an > exception for almost everything. But if you have defined an exception for one > special case, to interrupt your code, and catch such an exception you will > always know why this exception has been thrown. > -- > Christian Stoller > LEONEX Internet GmbH Hi, I believe that the example you provided, the one with 'BadCredentialsException', is a good example of a bad design and usage of exceptions, at least from my point of view. The fact that frameworks like Symfony2, Zend Framework or other php libraries/frameworks (ab)use the exceptions it doesn't mean that it's a good thing or you should have exceptions for everything. The provided example could just as well return false; for the login function and that's it, no? Exceptions should be used for exceptional cases where the application can't recover automatically from them. They are, even as their name suggests, exceptional cases, while a bad credential for a user login is not :) I also believe, and I might not be the only one with this, that exceptions used for flow control is a good sign of bad design. If you follow this way of thinking, everytime you throw an exception, you would want to catch it and perform some work with it, like logging it for example. So why would you make the variable optional then? Best regards Florin Patan https://github.com/dlsniper http://www.linkedin.com/in/florinpatan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Announcing RFC 'Anonymous Catches'
On 25 June 2013 22:23, Johannes Schlüter wrote: > On Tue, 2013-06-25 at 13:19 -0700, Stas Malyshev wrote: >> Hi! >> >> > If I'm to understand this RFC correctly, it is nothing more than a >> > random suggestion someone posed in the form of a tweet and the author is >> > saying why not add it since it's not hard to implement. So in summation >> >> Well, here we go - this is why not add it, because it makes working with >> such code harder without actually benefiting anybody. > > +1 > > Right now I set a breakpoint in my editor and look at an exception even > if it is not used, in future I'd have to change the code for that. Hrm, this is a very good point! >> > So this entire discussion can be summed up nicely with "Let's make the >> > variable optional because... why not?". >> >> "Why not" is usually not a very good principle of language design, IMO. Nothing more to add. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RE: Announcing RFC 'Anonymous Catches'
>> But I think it looks a bit cleaner if the variable could be omitted, >> if it's not needed ;-) > > I don't think we need to change the language because Netbeans can't > figure out how catch blocks work. The Netbeans thing was just an example/addition. > It's not used by you - which btw is usually not a good idea - if you've > got an exception, you usually should somehow react to it - at least log > it or something, that's what the exceptions are for, if the situation > does not require special handling it shouldn't be an exception. But it If you have an exception like `BadCredentialsException` and throw it during authentication if the user has entered wrong login data, than you have such a situation right? But do you need any further information? No - in the catch block it may be enough to create a message for the user saying: "wrong username or password". Maybe you only use generic exceptions like `RuntimeException`. This can be an exception for almost everything. But if you have defined an exception for one special case, to interrupt your code, and catch such an exception you will always know why this exception has been thrown. -- Christian Stoller LEONEX Internet GmbH
Re: [PHP-DEV] RE: Announcing RFC 'Anonymous Catches'
On Tue, 2013-06-25 at 13:19 -0700, Stas Malyshev wrote: > Hi! > > > If I'm to understand this RFC correctly, it is nothing more than a > > random suggestion someone posed in the form of a tweet and the author is > > saying why not add it since it's not hard to implement. So in summation > > Well, here we go - this is why not add it, because it makes working with > such code harder without actually benefiting anybody. +1 Right now I set a breakpoint in my editor and look at an exception even if it is not used, in future I'd have to change the code for that. > > So this entire discussion can be summed up nicely with "Let's make the > > variable optional because... why not?". > > "Why not" is usually not a very good principle of language design, IMO. +100 johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Announcing RFC 'Anonymous Catches'
On Tue, Jun 25, 2013 at 4:14 PM, Joost Koehoorn wrote: > On 25 juni 2013 at 22:06:40, Sherif Ramadan (theanomaly...@gmail.com) > wrote: > > > So this entire discussion can be summed up nicely with "Let's make the > variable optional because... why not?". > Correct. The tweet was actually a serious request and grounded (see > http://news.php.net/php.webmaster/16092 as an earlier response to you). > So the reason to make it optional is not really "why not?", there is some > reasoning behind it. > All of those reasons are pretty much a circuitous justification for writing bad code, in my opinion. None of the things mentioned in that mail are an actual reason for why you would need to remove the variable, to be completely frank. Primarily the reason I chose not to respond to it. When the argument is "we need to remove it because I'm not using it" there really is no argument here.
Re: [PHP-DEV] RE: Announcing RFC 'Anonymous Catches'
Hi! > If I'm to understand this RFC correctly, it is nothing more than a > random suggestion someone posed in the form of a tweet and the author is > saying why not add it since it's not hard to implement. So in summation Well, here we go - this is why not add it, because it makes working with such code harder without actually benefiting anybody. > So this entire discussion can be summed up nicely with "Let's make the > variable optional because... why not?". "Why not" is usually not a very good principle of language design, IMO. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Announcing RFC 'Anonymous Catches'
On 25 juni 2013 at 22:06:40, Sherif Ramadan (theanomaly...@gmail.com) wrote: On Tue, Jun 25, 2013 at 3:50 PM, Stas Malyshev wrote: Hi! > IMO actually it *makes* the code clearer, because $ignoredException is > not used, though a variable name like $ignored is self-explanatory, > too. It's not used by you - which btw is usually not a good idea - if you've got an exception, you usually should somehow react to it - at least log it or something, that's what the exceptions are for, if the situation does not require special handling it shouldn't be an exception. But it may be very useful for debugging, for example. Especially if somebody other than you looks at this code and tries to figure out what is going on. Removing vital information - like ability to see which exception was thrown - just to save 3 keystrokes - looks like a very misguided idea to me. Not to down-play the importance of what you're saying, since I fully agree with it, but he is saying that this isn't a key-stroke saving proposition. If I'm to understand this RFC correctly, it is nothing more than a random suggestion someone posed in the form of a tweet and the author is saying why not add it since it's not hard to implement. So in summation this is one of those "nice to have" features that has little cost and very little benefit. And I'm referring only to making the Exception variable optional (not the anonymous catch -- I'm entirely opposed to that part). So this entire discussion can be summed up nicely with "Let's make the variable optional because... why not?". Correct. The tweet was actually a serious request and grounded (see http://news.php.net/php.webmaster/16092 as an earlier response to you). So the reason to make it optional is not really "why not?", there is some reasoning behind it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Announcing RFC 'Anonymous Catches'
On Tue, Jun 25, 2013 at 3:50 PM, Stas Malyshev wrote: > Hi! > > > IMO actually it *makes* the code clearer, because $ignoredException is > > not used, though a variable name like $ignored is self-explanatory, > > too. > > It's not used by you - which btw is usually not a good idea - if you've > got an exception, you usually should somehow react to it - at least log > it or something, that's what the exceptions are for, if the situation > does not require special handling it shouldn't be an exception. But it > may be very useful for debugging, for example. Especially if somebody > other than you looks at this code and tries to figure out what is going > on. Removing vital information - like ability to see which exception was > thrown - just to save 3 keystrokes - looks like a very misguided idea to > me. > > Not to down-play the importance of what you're saying, since I fully agree with it, but he is saying that this isn't a key-stroke saving proposition. If I'm to understand this RFC correctly, it is nothing more than a random suggestion someone posed in the form of a tweet and the author is saying why not add it since it's not hard to implement. So in summation this is one of those "nice to have" features that has little cost and very little benefit. And I'm referring only to making the Exception variable optional (not the anonymous catch -- I'm entirely opposed to that part). So this entire discussion can be summed up nicely with "Let's make the variable optional because... why not?".
Re: [PHP-DEV] RE: Announcing RFC 'Anonymous Catches'
Regarding all of the discussion about the unused variable: If your catch blocks are too long or too complicated to be able to tell that the variable is unused, then I highly suggest you refactor that section. --- To me, the only maybe-useful portion of this discussion would be the empty catch which is more clear that it is a final resort catch than just catching \Exception. Apparently the opinions on this are quite divided, though.
Re: [PHP-DEV] RE: Announcing RFC 'Anonymous Catches'
Hi! > IMO actually it *makes* the code clearer, because $ignoredException is > not used, though a variable name like $ignored is self-explanatory, > too. It's not used by you - which btw is usually not a good idea - if you've got an exception, you usually should somehow react to it - at least log it or something, that's what the exceptions are for, if the situation does not require special handling it shouldn't be an exception. But it may be very useful for debugging, for example. Especially if somebody other than you looks at this code and tries to figure out what is going on. Removing vital information - like ability to see which exception was thrown - just to save 3 keystrokes - looks like a very misguided idea to me. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Announcing RFC 'Anonymous Catches'
On 25 June 2013 20:17, Stas Malyshev wrote:
> Hi!
> I don't think we need to change the language because Netbeans can't
> figure out how catch blocks work. This change doesn't provide any
> functionality that wasn't available before it, and does not make the
> code clearer - on the contrary, IMO it makes debugging harder and people
IMO actually it *makes* the code clearer, because $ignoredException is
not used, though a variable name like $ignored is self-explanatory,
too.
> reading the code more confused. In PHP, we always valued clarity over
> brevity, and I think we should keep it this way.
Duh, I find that statement a bit brave, though ;)
.oO(__{get,set,call,etc…}, object operators)
--
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Announcing RFC 'Anonymous Catches'
Hi! > In such a case you do not need any `$e`variable. Netbeans for example > always highlight's these variables because it is not used anywhere. > But I think it looks a bit cleaner if the variable could be omitted, > if it's not needed ;-) I don't think we need to change the language because Netbeans can't figure out how catch blocks work. This change doesn't provide any functionality that wasn't available before it, and does not make the code clearer - on the contrary, IMO it makes debugging harder and people reading the code more confused. In PHP, we always valued clarity over brevity, and I think we should keep it this way. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Announcing RFC 'Anonymous Catches'
I, too, believes that omitting the exception variable is great.
In addition, anonymous catch blocks will shorten the code of "catch
(Exception $e)" so... is just a simpler way of writing - and that's what
PHP agenda aiming for, doesn't it? be a friendly and readable language.
Reading
try {
$foo->bar();
} catch {
show404Page();
}
For example, is readable, short and not contain any extra variables that we
didn't used.
On Tue, Jun 25, 2013 at 2:18 PM, Joost Koehoorn wrote:
> > Hi all,
> >
> > I just published an RFC that proposes to add catch-statement without
> needing to specify a variable, and support for fully > anonymous catches.
> >
> > Details can be found at:
> >
> > https://wiki.php.net/rfc/anonymous_catch
> >
> > Regards,
> >
> > Joost Koehoorn
> >
>
> Hi.
> I am not sure about complete anonymous catch statement (like try { } catch
> { }), but I really like the proposal for omitting the exception variable.
>
> Because in frameworks like Symfony there are defined and used a lot of
> special exception types for each cases.
> Here's an example that shows what I mean:
>
> try {
> $foo->authenticate($user);
> } catch (BadCredentialsException) {
> echo "Bad credentials";
> } catch (InactiveAccount) {
> echo "Sorry, your account is not active anymore.";
> } catch (CurlErrorOnAuthService) {
> echo "Please try again later, the login service is currently
> unavailable.";
> } catch (Exception) {
> echo "bla blubb";
> }
>
> In such a case you do not need any `$e`variable. Netbeans for example
> always highlight's these variables because it is not used anywhere. But I
> think it looks a bit cleaner if the variable could be omitted, if it's not
> needed ;-)
>
> Best regards
> Christian
> This is exactly the reason, yes!
>
> As stated in the RFC, I think it's best that we consider the two ways
> separately. Omitting the variable is a much smaller change (and requires
> very little code changes) than having a fully anonymous catch.
>
> I originally dived into this because of a question of Phil Sturgeon on
> twitter, requesting for making the variable optional. I took it one step
> further and made the whole thing optional, but surely we can decide to only
> make the variable optional, I can see how it's bad programming practice to
> have fully anonymous blocks (even though sometimes they may be used). Just
> throwing this out here to see what you think about it.
>
>
>
> Regards,
>
> Joost
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Re: [PHP-DEV] Re: Announcing RFC 'Anonymous Catches'
Hi,
Another two cents here.
* Skipping binding a parameter to the exception would make debugging
harder. When you're stepping through code that isn't working correctly to
find a problem and then it throws an Exception which is caught in catch
block that doesn't name it e.g.
try
{
$connection = $this->connectToServer();
$data = $this->prepareData();
// lots more lines
// of code
$response = $this->getResponse();
$connection->close();
}
catch (UnexpectedException)
{
$this->retry(3);//breakpoint here, how to inspect Exception?
}
You can't actually inspect the caught exception, unless you knew where it
was going to be caught ahead of time, and went in to modify the code to
name the Exception before you started debugging.
* The RFC says "Runtime needs to perform less checks." - I'm not an expert
on the performance cost of Exceptions but surely that must be irrelevant?
Exceptions should only happen in exceptional circumstances, so shaving a
couple of cycles from code that rarely gets called should not be a factor
in deciding this RFC.
* Throwing and catching raw \Exception classes is in general a bad pattern
and should only be rarely done, to avoid uncaught errors being shown to
end-users. It's a common anti-pattern for junior developers to catch (and
throw) \Exception rather than extending specific Exception classes for the
specific Exception that could occur.
I don't think we should be making it be the easier choice to write bad code
than to write good code.
I also don't think that it's a problem for someone coming from another
language to learn what the root Exception class is for a language. It's not
as if it's an obscure, hardly used part of the language - it's really quite
important.
Although not having to write the Exception type would make it easier for
some programmers to learn PHP, for people learning PHP as their first
language or people coming from other languages where the Exception type has
to be set, having the Exception type be optional would be one more thing to
learn.
Joost Koehoorn wrote:
"the type of an exception mostly tells enough about what happened"
I think that's only true when it's an 'expected' exception, e.g. the
ConnectionLostException from the RFC, where you almost always just want to
retry the operation.
When it's an unexpected exception e.g. caused by trying to read a corrupted
file, you almost always need to have at least log the message and in some
cases it is necessary to have additional information that can be presented
to the user in a nice format, rather than just the raw message itself. e.g.
class InsufficientCreditsException extends \Exception {
protected $creditsRequired;
public function __construct($creditsRequired, $message = null, $code =
0, Exception $previous = null){...}
}
allows an InsufficientCreditsException exception to bubble up from the call
to the external API all the way to the UI where '$creditsRequired' is
formatted nicely for the user.
Although with the RFC you could have each style of catch statement where
needed, having two different ways of writing catch statements would be
confusing when it doesn't need to be.
In summary, although this would make PHP easier to learn for a few people,
I think it makes debugging and writing good consistent code be harder, as
well as making PHP harder to learn for other people.
cheers
Dan
Re: [PHP-DEV] Re: Announcing RFC 'Anonymous Catches'
On Mon, Jun 24, 2013 at 7:49 PM, Joost Koehoorn wrote:
> On 25 juni 2013 at 01:20:04, Anthony Ferrara (ircmax...@gmail.com) wrote:
> Joost,
>
> First off, let me say welcome and thanks for the contribution!
>
> I have a couple of questions around the intended proposal.
>
> 1. How do you plan on handling the case where there are multiple catch
> blocks?
>
> try {
> code();
> } catch {
> doSomething();
> } catch {
> doSomethingElse();
> }
> As mentioned as latest sentence in the Proposal chapter, an anonymous
> catch can only be used as the latest catch, and there can only be one of
> them. This is also how my current implementation works.
>
> 2. You mention as a benefit "Better possibilities for static analysis
> tools". Can you elaborate on this? I don't see how this sort of a change
> would have any effect (as catch would be the same as the existing `catch
> (\Exception $e)`)...
> It's mostly for finding unused variables. I suppose that static analysers
> currently ignore unused exception variables, but they don't have to when
> this is accepted and can properly indicate unused exception variables.
>
> 3. What benefit short of not having to type `(\Exception $e)` would this
> have? Populating the symbol table is extremely cheap at this stage, because
> the variable is already compiled in (so no hash table lookup or anything).
> Performance wise it's indeed very minor and doesn't really matter. It's
> more that you're adding code indicating that only a specific exception is
> used, while that may not really be the case.
>
> Consider Java people --Java has Throwable as the superclass of Exception--
> they may not know that in PHP 'Exception' is the least-specific type and
> therefore used as catch-all.
>
> As for leaving of the variable, the type of an exception mostly tells
> enough about what happened (well, it should), so you don't have to inspect
> the exception's error code/message and thus don't need the exception object
> at all.
>
> Additionally, I would recommend changing the version target to 5.NEXT
> (which would be 5.6 in practice).
> Done!
>
>
>
> As far as my personal feelings, I'd like to get some other commentary
> first.
>
>
> Thanks again!!!
>
> Anthony
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I'm just going to weigh-in here with my two cents.
When I look at the facts objectively I don't see a reason to turn down this
proposal, but I also don't see much of a reason to accept it. My only fear
is that people will abuse anonymous catch blocks in situations where it
would have been better to just properly handle the Exception.
For example, if you're doing this in your code you're probably writing some
pretty bad code that's tough to debug...
try
{
$this->connectToServer();
} catch {
$this->retry(3);
}
Why are we throwing Exceptions if we only want to retry the connection in
the event that it failed? That would be more likely better handled by the
callee where the connection can be retired up to a timeout or number of
re-attempts until it fails permanently and then throws an Exception.
Exceptions should be like broken promises. If the promise the method or
function makes can't be kept it should throw an Exception to notify the
caller and the caller should decide how to proceed from there. If the
caller doesn't care that the promise could not be kept they probably have
very special circumstances to consider. So I can live with catch(Exception
$e) { /* ignore $e */ }, but that's my only objection. It's one purely from
a stand-point of promoting better code.
I understand a lot of other languages may allow this, but then again a lot
of other languages give you more room to shoot yourself in the foot than
PHP does.
I'm pretty neutral about this feature overall.
