Exception Hierarchy [WAS: Re: Top 5]

Denis Koroskin 2korden at gmail.com
Thu Oct 16 05:19:04 PDT 2008


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.  
However, you might want to get as much info as possible (so that it would  
be easier to track the issue) before terminating the application.  
Something like that, for example:

void main() {
    try {
         runApp();
    } catch (Error e) {
         logError(e.toString());
    } catch {
         logError("Unknown exception has been caught.");
    }
}



More information about the Digitalmars-d mailing list