Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62061
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.170 as permitted sender)
MIME-Version: 1.0
Sender: amaury.bouchard@gmail.com
In-Reply-To: <501F46BE.4040407@sugarcrm.com>
References: <CAH-PCH7874id459NTuMqL6pzL=feRtaWUAiPiSqPDa73tnFy9w@mail.gmail.com>
 <501F46BE.4040407@sugarcrm.com>
Date: Mon, 6 Aug 2012 09:43:13 +0200
Message-ID: <CAPaKmRn92oMHV7SzJiDrNoOvZxFESL4G=Mm6ObAmaq_VH_80BA@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Ferenc Kovacs <tyra3l@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=e89a8fb20606ece53f04c6940884
Subject: Re: [PHP-DEV] Error handling brainstorming
From: amaury@amaury.net (Amaury Bouchard)

--e89a8fb20606ece53f04c6940884
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

2012/8/6 Stas Malyshev <smalyshev@sugarcrm.com>

> Exceptions are different from PHP errors. For example, if you try to
> open a file and the file isn't there, throwing exception is a very
> annoying behavior (yes I know some languages do that, IMO it's wrong).
> The reason is that it's pretty normal and within normal set of
> situations to which code should be prepared, so you will either have to
> obsessively wrap everything with try/catch blocks or do exception typing
> like Java does. Both options are quite annoying. I think it's much
> better to just open file and check if the result is OK. Converting it to
> exception doesn't really improve situation, as if downstream code didn't
> handle it the upstream probably won't know what to do with that
> exception either. This leads to code like try { whatever(); }
> catch(Exception e) {}. I saw tons of that in Java.
>

Even a simple file opening can fail for different kind of reasons (the file
doesn't exists, it is not readable, on some OS it could be already opened
and thus locked). Most of the time, you don't care the reason, but
sometimes you want to be more precise. With exceptions, we have an elegant
way to manage all failures as a whole, or to differenciate each reason.

But you are right, it could be very annoying to write a lot of try/catch
blocks. Maybe we could think about something inspired from Lua's "protected
call" function [1]. A convenient mean to say =ABOK, I know this expression
may raise an exception, but I don't care, discard it silently please. I
will check if my variable has been set or not.=BB.

[1] : http://www.lua.org/pil/8.4.html

--e89a8fb20606ece53f04c6940884--