The Right Approach to Exceptions

Daniel Murphy yebblies at nospamgmail.com
Sun Feb 19 00:00:20 PST 2012


"Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message 
news:mailman.585.1329637995.20196.digitalmars-d at puremagic.com...
> On Sunday, February 19, 2012 18:44:30 Daniel Murphy wrote:
>> I assume you mean the _first_ catch block?
>
> Yes. I should have been more specific.
>
>> By the looks of it java 7 has this with an awful syntax.
>>
>> Maybe we should introduce implicit 'catch fallthrough':
>>
>> void fun()
>> {
>>     try { something; }
>>     catch (ExceptionA) {} // falls through implicitly
>>     catch (ExpcetionB)
>>     { // handle both A and B
>>         break;
>>     }
>>     catch (ExceptionC)
>>     {
>>         // handle exception C
>>         break;
>>     }
>> }
>
> That wouldn't work, because it would make it so that ignore an exception 
> in
> the middle if you wanted to (much as that's generally bad practice). It 
> would
> also have the problem that you couldn't access the exception itself, and 
> while
> you obviously wouldn't be operating on the exception's exact type 
> regardless,
> you might want to iteract with the functions on a common based class.
>
> So, while at first glance, it seems like a good idea, I think that it has 
> too
> many issues as-is to work. It might be possible to adjust the idea to make 
> it
> workable though. Right now, it's possible to do it via mixins or calling a
> function inside the catch, but doing something similar to this would 
> certainly
> be nice, assuming that we could sort out the kinks.
>
> - Jonathan M Davis

I wasn't really serious about implicit fallthrough.

Out of the syntaxes I could come up with:
catch(Ex1, Ex2 e)
catch(e : Ex1, Ex2)
catch(Ex1 | Ex2 e) // java 7 syntax, horrible

I like (e : list) the best.  Naturally it would also accept a type tuple of 
exceptions.

http://d.puremagic.com/issues/show_bug.cgi?id=7540 




More information about the Digitalmars-d mailing list