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

[H. S. Teoh]

On Wed, Feb 22, 2012 at 11:14:11AM +0100, deadalnix wrote:
> Le 22/02/2012 08:32, H. S. Teoh a écrit :
[...]
> >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.

I was thinking about using TypeInfo to match stuff up at runtime. But I
need to work through the details first to see if it's actually
implementable. This seems to be an area where language support would
help a lot.

Though it's better if we can do it without language support, so that we
can get this thing up and running and test it with real-life usage
before making language changes that may not benefit in the long run. :)


> 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.

Names are just identifiers, sure, but it does help to have a useful name
to help us think about the problem from a useful angle. For example if
we renamed Exception to Bug, the mechanics of the it (try, throw, catch)
would still work the same, but we would be likely to use it in the wrong
ways because "Bug" doesn't help us think about it in a useful way.


T

-- 
Why ask rhetorical questions? -- JC