Exception Hierarchy [WAS: Re: Top 5]

[Andrei Alexandrescu]

Jarrett Billingsley wrote:
> On Sat, Oct 11, 2008 at 5:04 PM, downs <default_357-line at yahoo.de> 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.
>>>
>> Errors are useful. There is a class of problems that should not be trivially recoverable, i.e. not if you don't know what you're doing.
>>
>> It's the class of problems that would not be caught in release mode.
>>
>> Why? Because if such problems are caught thoughtlessly, then the program behavior changes in release mode .. which is a big, BIG no-no.
>>
>> So ArrayBoundsError, AssertFailedError, and InvariantError are all valid, and should NOT be derived from Exceptions.
> 
> And by the same token, string-to-integer conversion methods should not
> throw an irrecoverable error.  I'm looking at you, ConvError.

ConvOverflowError too, right?

Andrei