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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
