Towards a better conceptual model of exceptions (Was: Re: The Right Approach to Exceptions)

[deadalnix]

Le 22/02/2012 08:32, H. S. Teoh a écrit :
> On Tue, Feb 21, 2012 at 08:56:03PM +0100, deadalnix wrote:
>> Le 21/02/2012 20:00, H. S. Teoh a écrit :
> [...]
>>> You're right, that would be unnecessary duplication, especially since
>>> an unhandled Condition becomes a thrown Exception anyway, and it's a
>>> very bad idea to duplicate the entire Exception hierarchy in
>>> Condition.
>>>
>>> Only thing is, then the handler will have to downcast the Exception
>>> to get to the useful info. This may lead to messy code. But it's
>>> something we should investigate.
>>>
>>
>> Yes, I'm aware of the problem and it is real. I have no good solution
>> for it now.
>
> I have an idea. What if handlers took *two* arguments, a Condition, and
> a (possibly derived) Exception object? The raise system would then match
> conditions to handlers by both the Condition type and derived Exception
> type. The handler then has access to the particular derived object that
> it wants to handle without needing to downcast. So it sorta simulates a
> catch(DerivedException).
>
Well I have no idea how to implement that. Let's put some thinking into 
this, it certainly an option. However, this require to create the 
Exception, even if in many cases, it will not be usefull.

About the name, it matters, but isn't the big issue here. When we have 
something working well, we could think about names. As the concept may 
be changed again, naming isn't that important.