Exception Hierarchy [WAS: Re: Top 5]

[Jarrett Billingsley]

On Sat, Oct 11, 2008 at 11:29 PM, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> wrote:
> 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?

And why the heck doesn't ConvOverflowError inherit from ConvError?