Exception Hierarchy [WAS: Re: Top 5]

[Bruno Medeiros]

Denis Koroskin wrote:
> On Thu, 16 Oct 2008 16:10:44 +0400, Bruno Medeiros 
> <brunodomedeiros+spam at com.gmail> wrote:
> 
>> Sean Kelly wrote:
>>> Andrei Alexandrescu wrote:
>>>> downs wrote:
>>>>
>>>>> 3) the Exception/Error problem (they're different things, they
>>>>> shouldn't inherit!)
>>>>
>>>> I think Exception should inherit Error.
>>>  I personally dislike the use of "Error" to denote exceptions of any 
>>> sort.  To me, errors are what /cause/ exceptions to be thrown.  For 
>>> this reason, in Tango and druntime, "Exception" is defined as the 
>>> top-level class from which all exceptions should derive (imagine 
>>> that), making it equivalent to your "Error" object.
>>>  With this in mind, I'd like to solicit opinions about how exceptions 
>>> should be categorized.  Should unrecoverable exceptions derive 
>>> directly from "Exception" with a sibling named something like 
>>> "RecoverableException" as the parent for recoverable exceptions?  Or 
>>> would a bit more structure be better?  I don't think it should be the 
>>> runtime's responsibility to define a complex exception hierarchy, but 
>>> there is clearly a desire to at least retain some distinction between 
>>> recoverable and unrecoverable errors and my naming-fu is not terribly 
>>> strong.
>>>   Sean
>>
>> I agree there should be a distinction between recoverable exceptions 
>> (normal exceptions) and nonrecoverable exceptions (contract 
>> failures?). I agree that "Exception" should be the name for normal 
>> exceptions. The others could be named "Error" or "Failure".
>> If we want the ability to catch these two separately, I don't see any 
>> other way other than having a third, top-level class, ie, a 
>> "Throwable", from which Exception and Error/Failure derive from.
>> But while one will certainly want to catch Exception's without 
>> catching Error's, I'm not 100% sure it would be useful to be able to 
>> easily catch an Error but not an Exception. Does anyone know of such a 
>> case?
>>
> 
> You shouldn't catch Error to recover the application, it should die. 

I understand well the meaning and implications of Errors and contract 
failures.
Despite their nature, it doesn't mean it's wrong to try to catch them. 
There's the example you mentioned, but there are others where you want 
to catch them and not terminate the application, such as unit testing, 
or catching an error in a plug-in in a modular application (although the 
feasibility of maintaining a working/stable process of a modular 
application written in a systems-language, when one of it's plug-ins 
fails, is somewhat dubious).


-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D