I agree with Amaury. Although, it is rather smelly code to use try/catch as control flow instrument, in some situations it is clearer to do it this way. I think the new construct would be especially useful if one just wants to log errors (no further exception handling is necessary) as shown in previous examples.
-----Ursprüngliche Nachricht----- Von: amaury.bouch...@gmail.com [mailto:amaury.bouch...@gmail.com] Im Auftrag von Amaury Bouchard Gesendet: Samstag, 27. April 2013 19:23 An: Daniel Macedo Cc: Ferenc Kovacs; Julien Pauli; PHP Internals; Patrick Schaaf Betreff: Re: [PHP-DEV] Continued try blocks 2013/4/27 Daniel Macedo <admac...@gmail.com> > Sorry but I disagree, I think you're approaching try-catch wrong. > > You shouldn't have a try-catch that *can* continue on the next line > after the throw. > What you should do is have decoupled code that handles _their own > exceptions_ nicely and either cleans up after itself else it rethrows > the exception/a new one. > > Any top level try-catch is supposed to be a control structure with one > of two chances: either lines 1-N go smoothly and no exceptions are > thrown, or Exception_X is thrown and you clean up on it's catch block... > It's an opinion, a software engineering choice. Not something that must be enforced by the language. It could be very useful in some situations, not all the time (as traits, for example). Ideally, every errors (in fact, any abnormal situation) should raise an exception, right? OK, but that doesn't mean that any abnormal situation should be able to break execution flow, with no other solution than writing more code. Also remember that you have the finally block. > Can you explain how the finally block can help in my example? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
