DIP33: A standard exception hierarchy

[Jacob Carlborg]

On 2013-04-02 19:02, Steven Schveighoffer wrote:

> Right, but what I see here is that the language uses one set of criteria
> to determine whether it should catch, but it's difficult to use that
> same criteria in order to process the exception.  It's not easy to
> switch on a class type, in fact it's downright ugly (maybe we need to
> come up with a way to do that in normal code too).

That's kind of breaking the whole point of OO and virtual functions, you 
should not need to know the exact type.


> Yes.  I won't forget to re-throw the exception.  Plus, it seems that you
> are saying "catch this, but if it's also that, then *really* catch it".
> I think the catch is a one-shot deal, and should be the final
> disposition of the exception, you should rarely have to re-throw.
> Re-throwing has it's own problems too, consider this possibility:
>
> catch(ErrnoException ex) if(ex.errno == EBADF || ex.errno == EBADPARAM)
> {
>     // handle these specifically
> }
> catch(Exception ex)
> {
>     // handle all other exceptions
> }
>
> I think you would have to have nested try/catch statements to do that
> without something like this.

I'm just trying to exhaust all exiting language constructs first, before 
adding new ones.

> I mean it's a waste of code space and template bloat.  Not a waste to
> create the exception.

I see.

-- 
/Jacob Carlborg