[dev] Previous exceptions for Horde_Exception

[Chuck Hagenbuch]

Quoting Gunnar Wrobel <p at rdus.de>:

> 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.

Given that this is the dev branch, why bother with Horde_Exception_Deprecated?

The 3 use cases:

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).

Make sense to me. Can we just go there?

-chuck