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?
>
