The Right Approach to Exceptions

[deadalnix]

I don't think the Condition should be an Exception. I think it should 
provide a method that throw.

class Condition {
     void throw() pure {           // Or make it abstract
         throw new Exception();
     }
}

If no handler is found, this method is called. The handler can also call it.

It is very important to separate the Condition and the Exception. 
Several Condition may use the same Exception.

BTW, I don't think that something that can be implemented as lib should 
be added in the core language.

Condition may be use using something like raise(new 
MyCondition(params)); with raise from std.condition .

Alternatively, we could go metaprogramming for Condition, just like we 
did for Range.

Le 20/02/2012 21:18, H. S. Teoh a écrit :
>
>> 6/ This mecanism is provided as a lib.
>
> Not necessarily; it would be nice to have language support. But at least
> it's implementable as a lib (as I've shown), so we don't have to invest
> the time and effort to implement language support until we're sure it's
> a good idea, after thorough testing with the lib.
>
>
>> 7/ The mecanism is provided as a richer way to use Exceptions.
>>
>> Is it a solid base to start on ? I seems we need to start working on
>> std.condition ;) BTW, do we need language support to implement that ?
>> I don't think so, but I'm quite new to the issue.
>
> I'm not sure yet, but probably language support is be needed to reduce
> the amount of syntax you need to write just to define Conditions. Unless
> we can figure out a clever way of using templates or mixins or some such
> to make it easier to write.
>
> Ideally, you'd want to declare Conditions inside the catch block of the
> function, instead of making a separate class definition outside. But I'm
> not sure how to make such a thing work if the handler needs to know what
> methods are available in the first place. Perhaps a compromise is to use
> some templates with mixins to generate code for the Condition subclass
> and for the custom catch block for handling recovery strategies.
>
> Also, another issue that's still unclear to me is, if no handler is
> found and the Condition gets thrown, does it still make sense to throw
> the Condition object? Because once the stack unwinds, the recovery
> methods are probably no longer meaningful. Also, the fact that no
> handler was found means that no handler will ever be found, so the stack
> will just unwind to a catch block. And it's doubtful that at that level,
> the recovery options encoded in the Condition are usable at all.
>
> So some parts of this system need some rethinking.
>
>
> T
>