On Tue, Jun 25, 2013 at 12:54 AM, Joost Koehoorn
<[email protected]> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
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