Suggestion: Syntactic sugar for Exception handling in D2

[Tomasz Sowiñski]

Oh God, the example already compiles in D (and a few other languages, I guess). I'm sorry.

Tomasz Sowiñski Wrote:

> I like it. Although it's only sugar you're right -- it helps reading a bit. But I would allow (or even require) "try" before a block of code:
> 
> if (condition) try {
>     ...
> } catch (Exception ex) {
>     ...
> }
> 
> Seeing "try" there cuts down on the gray matter needed to understand what it does. And just not to stray too much from the C-family.
> 
> Tomek
> 
> Ulrik Mikaelsson Wrote:
> 
> > One thing I often encounter in D, and other languages, is functions looking something like;
> > 
> > void myfunc(Obj input)
> > {
> >    try {
> >      do_something(input);
> >    } catch (SomeException e) {
> >      handle_error(e);
> >    }
> > }
> > 
> > While there's no real problem with this code, I have some experience from Ruby, which has added some syntactic sugar regarding this, making all code-blocks a potential "try-clause", if there's a catch-block (or finally).
> > 
> > In D, it would look something like (and have the exact same semantic meaning of the code above);
> > 
> > void myfunc(Obj input)
> > {
> >    do_something(input);
> > }
> > catch (SomeException e)
> > {
> >    handle_error(e);
> > }
> > 
> > IMHO, this syntactic addition gives a few advantages;
> >   * Makes the code slightly more readable, since the "exceptional" code-paths are clearly separated
> >   * Biases me as a programmer to think a little bit more of exactly what exceptions can be raised in a function, improving my code-quality.
> >   * When I'm about to write a try-clause, makes me think twice if the code could not be extracted as a separate method instead (if I can only figure a good name for it), also improving readability and code-structure.
> > 
> > To sum up; while this is purely syntactic sugar, my personal experience from Ruby is that this syntax encourages better coding on my part, which I think would be a good thing to incorporate in D.
> > 
> > One thing, I'm pondering though, is exactly in what blocks this should be allowed, and what semantics should apply.
> >   * Inner anonymous functions? 
> >   * If statements?
> >   * For-loops? If so, is the try for the entire loop, or per iteration?
> >   * How does this relate to the contract-programming-features in D?
> > 
> > Comments / opinions on this, anyone?
>