Announcing RFC 'Anonymous Catches'

11 years ago by Joost Koehoorn — view source

unread

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

11 years ago by Anthony Ferrara — view source

unread

Joost,

First off, let me say welcome and thanks for the contribution!

I have a couple of questions around the intended proposal.

How do you plan on handling the case where there are multiple catch
blocks?

try {
code();
} catch {
doSomething();
} catch {
doSomethingElse();
}
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))...
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).

Additionally, I would recommend changing the version target to 5.NEXT
(which would be 5.6 in practice).

As far as my personal feelings, I'd like to get some other commentary first.

Thanks again!!!

Anthony

11 years ago by Joost Koehoorn — view source

unread

Joost,

First off, let me say welcome and thanks for the contribution!

I have a couple of questions around the intended proposal.

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.

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.
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

11 years ago by Sherif Ramadan — view source

unread

On Mon, Jun 24, 2013 at 7:49 PM, Joost Koehoorn joost.koehoorn@gmail.comwrote:

Joost,

First off, let me say welcome and thanks for the contribution!

I have a couple of questions around the intended proposal.

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.

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.

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

--

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.

11 years ago by Florin Patan — view source

unread

On Tue, Jun 25, 2013 at 12:54 AM, Joost Koehoorn
joost.koehoorn@gmail.com 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,

First of, considering that you would only save three characters by
having the ' $e' removed, I don't see how it would make things easier
to learn. I mean if you can't learn that maybe you should look into
something else that's not related to programming :)

Having this: "* Avoid indication of a specific exception type" could
be considered as a possible bad practice, just as you were saying that
catch(\Exception $e) is. Also, it you can add the other ten characters
that you save when typing \Exception but does it worth it?

How do you plan to handle this: * Note that there may only be one
anonymous catch-statement, and it has to be the last one. Throw a
fatal error? If not then what, nothing?

What are the performance downsides of having this check in place? I do
understand that you mentioned: "* Runtime needs to perform less
checks. No need to update the symboltable, no need to check exception
inheritance. " but wouldn't that be replaced by what I'm asking about?
If I could read/understand C better I wouldn't ask for this.

Could you also please elaborate this: "* Better possibilities for
static analysis tools"?

As for: * People from other languages such as C#, Python and Ruby
expect this to work I think it is often pointed out when requesting
features such as function/method return type hinting (I'm planning a
RFC for that), named parameters, threads and other stuff that this
ain't C#, Java, Python, Ruby or whatnot so.. what's the official
position on this? Do we want PHP like the other languages or not (and
I won't say more on this here/now)?

Also, the code sample is not that good. If you want to reflect a good
quality scenario, it should be more like:

while (true) {
try
{
$this->connectToServer();
break;
}
catch (ConnectionFailedException)
{
sleep(3);
}
}

And I think the RFC should also add a: Disadvantages section so that
it could help people looking on it and proving that you've done all
the research correctly.

Thanks

Florin Patan
https://github.com/dlsniper
http://www.linkedin.com/in/florinpatan

11 years ago by Nikita Popov — view source

unread

On Tue, Jun 25, 2013 at 12:54 AM, Joost Koehoorn
joost.koehoorn@gmail.comwrote:

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

No opinion on leaving off $e, but I'm against the generic catch{} statement.

Looking at the Python docs, they don't see particularly fond of the
wildcard-except themselves:

The last except clause may omit the exception name(s), to serve as a
wildcard. Use this with extreme caution, since it is easy to mask a real
programming error in this way! It can also be used to print an error
message and then re-raise the exception (allowing a caller to handle the
exception as well):

Furthermore a wildcard-catch is bad for forwards compatibility. Right now
all exceptions extend Exception, but this doesn't have to stay so. E.g.
Python has additional exceptions above that for handling stuff like signal
interrupts or die()s and I think it's not unlikely that we will introduce
something like this in PHP too. You normally do not want to catch those,
but a wildcard-catch would do this.

Thus I think it's better to stays explicit and keep it at catch(Exception).

Nikita

11 years ago by Michael Wallner — view source

unread

No opinion on leaving off $e, but I'm against the generic catch{} statement.

I second the concerns about empty catch{}.

--
Regards,
Mike

11 years ago by Joost Koehoorn — view source

unread

On 25 June 2013 17:07, Nikita Popov nikita.ppv@gmail.com wrote:

No opinion on leaving off $e, but I'm against the generic catch{} statement.

I second the concerns about empty catch{}.

--
Regards,
Mike
As most of you seem to discard the idea about and empty catch (I can see why, no problems), maybe it's best to focus on only leaving of the variable then, that's something most of you seem to agree with, until now.

11 years ago by Patrick ALLAERT — view source

unread

2013/6/25 Nikita Popov nikita.ppv@gmail.com:

but I'm against the generic catch{} statement.

I'm sharing Nikita's opinion, with the difference of a bit more
enthusiasm on leaving off the variable as it could make it more
obvious that there is no intention in using the variable, and that no
memory should be kept for it. This might be better than doing:

try {
[...]
} catch (Exception $ignore) {
unset($ignore);
}

[...]

However, I see other cases where a variable is technically required
but not used:

abstract class AbstractPrinter {
abstract public function print($message);
}

class Printer extends AbstractPrinter {
public function print($message) {
echo $message;
}
}

class BlackholePrinter extends AbstractPrinter {
public function print($message) {
}
}

In the previous example, $message is not "used" in
BlackholePrinter::print() (as well as in AbstractPrinter::print()).
How do you intend to make that consistent with: catch(Exception) ?

Patrick

11 years ago by Joost Koehoorn — view source

unread

2013/6/25 Nikita Popov nikita.ppv@gmail.com:

but I'm against the generic catch{} statement.

I'm sharing Nikita's opinion, with the difference of a bit more
enthusiasm on leaving off the variable as it could make it more
obvious that there is no intention in using the variable, and that no
memory should be kept for it. This might be better than doing:

try {
[...]
} catch (Exception $ignore) {
unset($ignore);
}

[...]

However, I see other cases where a variable is technically required
but not used:

abstract class AbstractPrinter {
abstract public function print($message);
}

class Printer extends AbstractPrinter {
public function print($message) {
echo $message;
}
}

class BlackholePrinter extends AbstractPrinter {
public function print($message) {
}
}

In the previous example, $message is not "used" in
BlackholePrinter::print() (as well as in AbstractPrinter::print()).
How do you intend to make that consistent with: catch(Exception) ?

Patrick

Your inheritance example is something that I do not have a good solution for (I don't think there is one) but with Exceptions it's different, because there the solution is obvious, unambiguous and expected.

That it also happens to be easy to implement is good to know, it means that the effects of this change are totally obvious (because only ONE opcode has to be changed, so there is only an effect on this ONE opcode, other code is not affected in any way, that's good to know).

11 years ago by Joost Koehoorn — view source

unread

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 $evariable. 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

11 years ago by Yahav Gindi Bar — view source

unread

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 joost.koehoorn@gmail.comwrote:

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 $evariable. 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

11 years ago by Stas Malyshev — view source

unread

Hi!

In such a case you do not need any $evariable. 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

11 years ago by Michael Wallner — view source

unread

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

11 years ago by Stas Malyshev — view source

unread

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

11 years ago by Levi Morrison — view source

unread

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.

11 years ago by Sherif Ramadan — view source

unread

On Tue, Jun 25, 2013 at 3:50 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:

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?".

11 years ago by Joost Koehoorn — view source

unread

On Tue, Jun 25, 2013 at 3:50 PM, Stas Malyshev smalyshev@sugarcrm.com 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.

11 years ago by Sherif Ramadan — view source

unread

On Tue, Jun 25, 2013 at 4:14 PM, Joost Koehoorn joost.koehoorn@gmail.comwrote:

On 25 juni 2013 at 22:06:40, Sherif Ramadan (theanomaly.is@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.

11 years ago by Stas Malyshev — view source

unread

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

11 years ago by johannes@schlueters.de — view source

unread

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

11 years ago by Michael Wallner — view source

unread

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

11 years ago by Joost Koehoorn — view source

unread

On 25 June 2013 22:23, Johannes Schlüter johannes@schlueters.de 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.

11 years ago by Sherif Ramadan — view source

unread

On Wed, Jun 26, 2013 at 7:54 AM, Joost Koehoorn joost.koehoorn@gmail.comwrote:

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.

</my two cents

11 years ago by Christian Stoller — view source

unread

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

11 years ago by Florin Patan — view source

unread

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

11 years ago by Christian Stoller — view source

unread

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

11 years ago by Joost Koehoorn — view source

unread

On Tue, Jun 25, 2013 at 12:54 AM, Joost Koehoorn
joost.koehoorn@gmail.com 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,

First of, considering that you would only save three characters by
having the ' $e' removed, I don't see how it would make things easier
to learn. I mean if you can't learn that maybe you should look into
something else that's not related to programming :)
I don't recall mentioning that this makes PHP easier to learn. It's really about avoiding introducing unused variables, which is currently required because the language simply requires and identifier there.

Having this: "* Avoid indication of a specific exception type" could
be considered as a possible bad practice, just as you were saying that
catch(\Exception $e) is. Also, it you can add the other ten characters
that you save when typing \Exception but does it worth it?
I don't really care about saving a few characters, that's not what this is about. I can see that a catch-all can be considered bad practice, but perform a Github search for catch (Exception $e) and find very much instances of this usage. In all of these situations it seems that only specific exceptions are caught, but that's not actually the case. We currently see that requiring an Exception type doesn't really enforce good programming practice, most instances simply use (\Exception $e) and have the same bad practice.

How do you plan to handle this: * Note that there may only be one
anonymous catch-statement, and it has to be the last one. Throw a
fatal error? If not then what, nothing?
In my current implementation, it's simply a syntax error and thus will never result in compiled code.

What are the performance downsides of having this check in place? I do
understand that you mentioned: "* Runtime needs to perform less
checks. No need to update the symboltable, no need to check exception
inheritance. " but wouldn't that be replaced by what I'm asking about?
If I could read/understand C better I wouldn't ask for this.
As it's directly enforced by the language grammer, Bison (the parser generator) won't accept invalid use of the anonymous catch, and thus no additional runtime checks are necessary.

Could you also please elaborate this: "* Better possibilities for
static analysis tools"?
This is about unused variables. When you use an IDE or tools such as PHPMD, they will warn you about unused variables in your code. Exception variables are simply required by the language, even though you may not actually use them, thus generating unused variables warnings (or the analyser doesn't flag exception variables, in which case you miss unused variables) which you cannot solve.

As for: * People from other languages such as C#, Python and Ruby
expect this to work I think it is often pointed out when requesting
features such as function/method return type hinting (I'm planning a
RFC for that), named parameters, threads and other stuff that this
ain't C#, Java, Python, Ruby or whatnot so.. what's the official
position on this? Do we want PHP like the other languages or not (and
I won't say more on this here/now)?
I can agree with you here, PHP has its own things and is different from other languages for a reason. I'm mentioning this because I can see how Python/Ruby developers working with PHP may find this a flaw in PHP, giving them another reason to bitch about PHP.

Also, the code sample is not that good. If you want to reflect a good
quality scenario, it should be more like:

while (true) {
try
{
$this->connectToServer();
break;
}
catch (ConnectionFailedException)
{
sleep(3);
}
}

And I think the RFC should also add a: Disadvantages section so that
it could help people looking on it and proving that you've done all
the research correctly.
I couldn't really come up with disadvantages. Anonymous catch-statements may be considered bad coding practice, but look at the amount of developers simply using Exception as the type which is the same bad practice, only with the false indication that a specific type is expected. By allowing for not specifying the type at all, it's immediately clear that the intention was to not care about the type at all.

Thanks
----
Florin Patan
https://github.com/dlsniper
http://www.linkedin.com/in/florinpatan

Announcing RFC 'Anonymous Catches'

Thanks

"Why not" is usually not a very good principle of language design, IMO.

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.

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.

Best regards

Best regards

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.

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.