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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
