Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62074
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain apfelbox.net from 83.169.28.40 cause and error)
Message-ID: <50205956.5070903@apfelbox.net>
Date: Tue, 07 Aug 2012 01:55:02 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAH-PCH7874id459NTuMqL6pzL=feRtaWUAiPiSqPDa73tnFy9w@mail.gmail.com> <501F46BE.4040407@sugarcrm.com> <CAFMT4NqUVF-Q_TZ_toe_7NCgYBU3J02eVWp46wf=CYRyouWdNg@mail.gmail.com> <50200FBD.2010506@sugarcrm.com>
In-Reply-To: <50200FBD.2010506@sugarcrm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Error handling brainstorming
From: hello@apfelbox.net (Jannik Zschiesche)

Hi all,


Am 06.08.2012 20:41, schrieb Stas Malyshev:
> Hi!
>
>> Because checking that the returned variable is `!== FALSE` is *way*
>> better than throwing an exception, right?
> Yes, it is. You can control it, unlike the exception which you can not,
> unless, again, you wrap everything into try/catch on every kind of
> exception possible.
Well, if you use return codes, you have to wrap everything in 
if-statements (maybe more than one, for multiple error codes), so you 
don't actually gain anything here.


If you really need very fine-grained error reporting, you can also use 
error codes in the exceptions (although you might get a strange mix of 
both then - I would rather use typed exceptions... I mean, how many 
functions do you know, where you actually have to deal with 20 different 
types of errors [without using exceptions for control flow]).

You can avoid the mentioned problems with accidentally missing an 
exception by just using multiple catch blocks:


try {
  // ...
}
catch (FileNotFoundException $e)
{
  // do something for this exact error message
}
catch (Exception $e)
{
  // catch all other errors
}


What I really like when working with exceptions is that you have a 
"natural way of error bubbling". If you have a call stack of about 10 
functions and the last one returns null as error value, every of the 
other 9 functions needs to check for null and return null too (or do 
something else to hint for an error). If you use exceptions, all this 
work is done for you, so that you can handle the error on exactly the 
level, where you want it to be handled.


What Andrew also tried to say is, that with some kind of errors you just 
want the execution of your application to stop (and probably present an 
error message to the user by using a try-catch around your complete 
application) and not keep running, just because you forget to check a 
single return value and the program keeps running in an undefined state.

But I guess this boils down to the quite old question: do I want my 
application to crash (hard) to prevent bugs/corrupt data but create a 
bad UX for the user; or do I want it to keep running by any means, even 
if the handled and produced data may be just garbage? In the past, PHP 
did choose the second alternative (which can be - depending on the case 
- be both good and bad).



Just my thoughts.

Cheers,
Jannik