DIP33: A standard exception hierarchy

[H. S. Teoh]

On Tue, Apr 02, 2013 at 08:55:43AM +0200, Jacob Carlborg wrote:
> On 2013-04-02 01:52, Steven Schveighoffer wrote:
[...]
> >But I also hate having to duplicate catch blocks.  The issue is that
> >class hierarchies are almost never expressive enough.
> >
> >contrived example:
> >
> >class MyException : Exception {}
> >class MySpecificException1 : MyException {}
> >class MySpecificException2 : MyException {}
> >class MySpecificException3 : MyException {}
> >
> >try
> >{
> >    foo(); // can throw exception 1, 2, or 3 above
> >}
> >catch(MySpecificException1 ex)
> >{
> >    // code block a
> >}
> >catch(MySpecificException2 ex)
> >{
> >    // code block b
> >}
> >
> >What if code block a and b are identical?  What if the code is long
> >and complex?  Sure, I can put it in a function, but this seems
> >superfluous and verbose -- exceptions are supposed to SIMPLIFY error
> >handling, not make it more complex or awkward.  Basically, catching
> >exceptions is like having an if statement which has no boolean
> >operators.
> >
> >Even if I wanted to write one block, and just catch MyException, then
> >check the type (and this isn't pretty either), it's not exactly what
> >I want -- I will still catch Exception3.  If this is the case, I'd
> >rather just put an enum in MyException and things will be easier to
> >read and write.
> 
> The obvious solution to that would be to be able to specify multiple
> exception types for a single catch block:
> 
> catch (MySpecificException1, MySpecificException2 ex)
> {
> }
[...]

But what type will ex be, inside the catch block?


T

-- 
Государство делает вид, что платит нам зарплату, а мы делаем вид, что работаем.