The Right Approach to Exceptions

[Juan Manuel Cabo]

> That because you can't (shouldn't) push up implementations specific to a given subclass. Why don't we only have one
> class, Object, and add a Variant[string] there.
>
> Do you see how stupid that is.

As stupid as any database API which returns result items as Variant[string] or
string[string], but it works. (the sad part is that one has to rely a bit on
convention, but convention can be standardized (string constants) and measures
taken when deviated so that it is done gracefuly).

Do you have an alternative solution that allows to extend an exception
object with extra information, while keeping it the same class?

So if one removes the bad reasons to create new Exception types, then the
ones that DO get created are solid, standard, reusable, and can withstand
the test of time. Because they would be open for extension but closed for
source code modification.

--jm


On 02/21/2012 03:03 PM, Jacob Carlborg wrote:
> On 2012-02-21 17:57, Andrei Alexandrescu wrote:
>> On 2/21/12 10:50 AM, Juan Manuel Cabo wrote:
>>> I thought that an alternative to Variant[string] would be to have some
>>> virtual
>>> functions overrideable (getExceptionData(string dataName) or something).
>>> but they would all have to return Object or Variant, so it's the same
>>> thing.
>>
>> Exactly. By and large, I think in the fire of the debate too many people
>> in this thread have forgotten to apply a simple OO design principle:
>> push policy up and implementation down. Any good primitive pushed up the
>> exception hierarchy is a huge win, and any design that advocates
>> reliance on concrete types is admitting defeat.
>>
>> Andrei
> 
> That because you can't (shouldn't) push up implementations specific to a given subclass. Why don't we only have one
> class, Object, and add a Variant[string] there.
> 
> Do you see how stupid that is.
>