On Mon, Jun 24, 2013 at 9:39 AM, Joost Koehoorn <[email protected]>wrote:
> I'm very well aware of the fact that catching 'Exception' has the same > effect, but why require it when you don't care? Specifying a type indicates > that you do want a specific type (alright, the least specific one, but not > all people may know, especially Java people who have Throwable as > superclass of Exception), where you don't actually need one. > > > Leaving of the variable can help in finding unused variables. IDE's have > excellent static analysis tools and will tell you about unused variables, > so avoiding them in catch-statements when not used helps in making the > analysis more robust. > I'm glad that you're interested in contributing to PHP and I really want to encourage you to pursue contributions both now and in the future. Here are just a few minor suggestions that might help you along the way: - Try to use under quote rather than over-quote (it makes it easier to read the threads in the mailing list) - Give a quick read of the current RFCs that have been proposed around Exceptions in PHP [ https://wiki.php.net/rfc ] - Start some discussion around the idea on the internals mailing list [ [email protected]] to see how people might respond (this can even be after you write the RFC) This is by no means to deter you from writing your proposal. I welcome all those willing to help better PHP. However, I do like to caution people that are eager to propose new changes (especially to the language constructs) of how their changes may impact the PHP community at large and how useful or un-useful the change may prove to be. It's not a bad idea to make something better, but there is a cost to all improvements and some improvements are simply not worth their cost. That is not to say that this particular proposal may not be worth the cost (it very well may prove to be... we don't know yet). Here's my opinion on this (and I'm by no means the arbiter in this matter) about anonymous catch blocks. They are justified from a position of poor coding habit or practice. If you are catching exceptions and not caring about the Exception itself you are likely just rethrowing the Exception, which still requires the Exception variable and thus isn't a valid use case for this. If you are catching exceptions for any other reason where you don't care about the exception you are likely abusing Exceptions on a much larger scale. If the justification here is to change the language in order to satisfy the IDE's static analyses (or whatever nuisances it may introduce to the IDE) the answer is likely that the IDE is warning you about unused variables for good reason (i.e. you really should have been using them). I see no real justification to catch the exception and completely ignore it, that should require changing the language. If you insist on ignoring it there's no real cost to you, or your code, that PHP requires the variable. If you insist on changing the language to accommodate for not requiring the variable you only stand to lose. Here are a few points to consider... For one, this creates a larger diff in your code commits, should you want to go back and use the Exception later (you modify not only the catch block, but also the catch statement). Second, you promote laziness when the Exception is readily available to user-land code and allow it to be completely discarded by the language (we have the information available why are we throwing it away). Again, if the user really insists on ignoring the Exception they can simply do so (no need for us to discard it). Third, you have to consider the impact of the change on the entire community, since PHP is used by millions of people around the world. This is in fact one of the guidelines for writing an RFC that should be considered early on (see https://wiki.php.net/rfc/howto and https://blogs.oracle.com/opal/entry/the_mysterious_php_rfc_process) "Your RFC should talk about all PHP areas that will be affected: php.ini, different SAPIs, engine, extensions, etc. List similar features. List similar features in other languages. Link to references. Give an estimate of the actual positive impact to user code. Put the proposed voting options in the RFC so they can be included in its discussion."
