[dev] Previous exceptions for Horde_Exception

[Gunnar Wrobel]

Quoting Michael M Slusarz <slusarz at horde.org>:

> Quoting Gunnar Wrobel <p at rdus.de>:
>
>> This morning I moved some functionality from the Horde_Exception  
>> class into a separate Horde_Exception_Prior class and modified all  
>> calls where we provided Horde_Exception with either a PEAR error or  
>> an Exception as first argument.
>>
>> I did this in order to support previous exceptions as described in  
>> this proposal:  
>> http://framework.zend.com/wiki/display/ZFPROP/previous+Exception+on+Zend_Exception+-+Marc+Bennewitz
>>
>> Jan did not like the approach of introducing a new Exception class  
>> so I wanted to ask for feedback. I attach the log of the discussion  
>> I had with one. It should already cover some of the pros and cons.
>
> Haven't had a chance to look at this in depth yet, but at a cursory  
> glance I would agree with Jan - namely, we should have an  
> all-singing/all-dancing single point of contact (e.g.  
> Horde_Exception) that should do everything for us rather than  
> separate exceptions.  I don't think it is necessary for  
> Horde_Exception itself to exactly mirror PHP's exception interface  
> (e.g. Horde_Exception can have different parameter requirements for  
> its constructor vs. the native PHP Exception class).

I do actually agree. There is no specific reason why we should not use  
Horde_Exception as the one and only Exception class.

But the code we had in that class so far did not take the concept of  
previous exceptions into account.

There were three extensions to the PHP Exception class in the old  
Horde_Exception class:

1) You could throw an Exception into the $message argument
2) You could throw a PEAR Error into the $message argument.
3) You could throw the result of error_get_last() into the $code argument.

Considering the PHP Exception class from PHP >= 5.3.0 you would ...

1) ... throw the Exception ...
2) ... repackage a PEAR Error as Horde_Exception_Pear and throw it ...
3) ... repackage the error_get_last() result as  
Horde_Exception_LastError and throw it ...

... into the $previous argument of  
Horde_Exception::__construct($message, $code, $previous).

In all three cases you end up with a Horde_Exception and ultimately  
there is no need for the old code in Horde_Exception.

Both 2) and 3) are not yet implemented that way and we still use  
Horde_Exception the old way in many places. Originally  
Horde_Exception_Prior was named Horde_Exception_Deprecated and this  
might be the better name.

Cheers,

Gunnar

>  As far as I am concerned, Horde_Exception is meant to be an  
> abstraction layer that does exactly what is happening here: make the  
> details of differing unerlying exception APIs transparent.
>
> michael
>
> -- 
> ___________________________________
> Michael Slusarz [slusarz at horde.org]
>
>
> -- 
> Horde developers mailing list - Join the hunt: http://horde.org/bounties/
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe at lists.horde.org
>




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.horde.org/archives/dev/attachments/20100211/9e9eda1e/attachment-0001.bin>