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