Nathan Rixham schreef:
> ceo@xxxxxxxxx wrote:
>>> there is an art to using them, they compliment 'traditional' error
>>> handling, and I agree they can hinder if used badly.
>>
>> I don't think I've ever seen Exceptions used well...
>>
>> Invariably, I end up having to write a wrapper function around every
>> function implemented and catch all the Exceptions.
>>
>> Otherwise, my code is littered with try/catch blocks for every little
>> thing the other guy was too lazy to figure out how to handle gracefully.
>>
>> ymmv
>>
>
> i use them often, basically if a boolean false won't do its a case of
> throwing an exception.
>
> let's say you have:
>
> calls_fifty_methods($page_load_of_variables);
>
> wrap that bit in a try catch and you get
>
>
> try {
>
> calls_fifty_methods($page_load_of_variables);
>
> } catch ( DatabaseException $e) {
> // handle that error
> } catch ( FileNotFoundException $e) {
> // handle
> } catch ( VerySpecificException) {
> // handle
> } catch ( Exception $e ) {
> // didn't expect this, notify devs, error log it and do X Y Z
> }
>
> try firing back error codes or something from 50 methods down and you
> have a real can go wrong easily series of returning error codes and
> processing the same anyways; or you could take the echo some html
> approach from the function - which is wrong on so many levels or..
>
agreed, that basically the point, being able to defer the handling of
the problem to some code that knows what to do with it given the context,
if a DB object cannot connect to the DB how does it know what to do in
terms of handling the situation? ... in a webpage you may wish to
redirect, show an error msg or something else (which shouldn't be up
to the object in question and should therefore not be built into it),
in a CLI environment you'd want to do something else maybe.
wrapper functions to handle exceptions as Richard offered is actually
quite neat assuming that the wrapper functions are designed for a
given context (and that they can then assume to be able to handle
the given exception in a way suitable to the given context)
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
