Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:67184 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 97653 invoked from network); 27 Apr 2013 18:46:27 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Apr 2013 18:46:27 -0000 Authentication-Results: pb1.pair.com header.from=rstoll@tutteli.ch; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=rstoll@tutteli.ch; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain tutteli.ch designates 80.74.154.78 as permitted sender) X-PHP-List-Original-Sender: rstoll@tutteli.ch X-Host-Fingerprint: 80.74.154.78 ns73.kreativmedia.ch Linux 2.6 Received: from [80.74.154.78] ([80.74.154.78:44996] helo=hyperion.kreativmedia.ch) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 2F/60-29666-10D1C715 for ; Sat, 27 Apr 2013 14:46:26 -0400 Received: (qmail 15705 invoked from network); 27 Apr 2013 20:46:21 +0200 Received: from ip-31-205-11-203.ask4internet.com (HELO RoLaptop) (31.205.11.203) by ns73.kreativmedia.ch with (AES128-SHA encrypted) SMTP; 27 Apr 2013 20:46:21 +0200 Cc: "'PHP Internals'" References: <170891005.EmXIrsICLC@rofl> In-Reply-To: Date: Sat, 27 Apr 2013 19:46:19 +0100 Message-ID: <000301ce4377$8201ac40$860504c0$@tutteli.ch> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG3O73jjKy861OdQIbwQgwza2r8tgFDS1K+AaljtngCr7wH+gITj8bMAOOXyFAA764Xg5jMW1wQ Content-Language: de-ch Subject: AW: [PHP-DEV] Continued try blocks From: rstoll@tutteli.ch ("Robert Stoll") I agree with Amaury.=20 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.=20 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.=20 -----Urspr=FCngliche Nachricht----- Von: amaury.bouchard@gmail.com [mailto:amaury.bouchard@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 > 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=20 > after the throw. > What you should do is have decoupled code that handles _their own=20 > exceptions_ nicely and either cleans up after itself else it rethrows=20 > 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=20 > 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?