On Saturday, February 25, 2012 07:29:01 Kevin Cox wrote: > I think there should also be multiple catches so that you can deal with > different exceptions different ways without trying to upcast them over and > over again.
You can do that now. Just catch each specific exception type that you want to catch. The issue is when you want to catch a specific set of exceptions and treat them all the same, but you don't want to treat all exceptions of their common type the same. catch(e : UTFException, UnicodeException) { } catch(StringException e) { } catch(Exception e) { } Presently, the only common type that UTFException and UnicodeException share is Exception. So, if we didn't have a syntax like I use above (which we currently don't have), if either have to catch UTFException and UnicodeException separately and duplicate the code within the catch block for each of them (though you could use a mixin or a function to reduce the duplication), or you'd have to catch Exception, and then do something like catch(Exception e) { if(cast(UTFException)e || cast(UnicodeException)e) { } else if(cast(StringException)e) { } else { } } That's far uglier and is completely unable to take advantage of catch's ability to catch by type. Also, what if you didn't really want to catch Exception? e.g. catch(e : UTFException, UnicodeException) { } catch(StringException e) { } Then, if you went to catch Exception, because it was the common type, you'd have to rethrow the exception if it wasn't one of the 3 that you cared about, which resets the stack trace. _That_ is the problem that this is trying to solve. If you really want to catch exceptions individulally by their specific types, then you can already do that just fine. - Jonathan M Davis