Exception Hierarchy [WAS: Re: Top 5]

Bruno Medeiros brunodomedeiros+spam at com.gmail
Thu Oct 16 05:10:44 PDT 2008


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?

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



More information about the Digitalmars-d mailing list