Re: Suggestion: Syntactic sugar for Exception handling in D2
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?
>
Re: Suggestion: Syntactic sugar for Exception handling in D2
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?
Re: SCHEDULED for deprecation
Georg Wrede Wrote: > Yes. It's a matter of principle, that a compiler should behave the same, > no matter what the wall clock says. (Commercial beta versions excluded, > which totally stop working at a fixed date, but that's different.) > > What could be useful is a switch --show-deprecated that simply puts out > a list of the currently deprecated functions and things. But that's > asking for too much, I admit. Rather, the change log would be the right > place for that. There they should be in one place, diligently listed. > I proposed this because, from my experience, no one would switch such a switch. Time-pressure erradicates all thoughts about maintanance, as long as it works/compiles. Tomek
Re: SCHEDULED for deprecation
Nick Sabalausky Wrote: > ; "ski" wrote > in message news:gtv3u0$2q0...@digitalmars.com... > > This phrase gave me an idea for a small feat: > > > > deprecated(2009-4-19) void foo(); > > > > Compiling references to the deprecated declaration *before* the > > deprecation date would result in a *warning*. > > Compiling the deprecated declaration OR any reference to it *after* the > > date would result in an *error*. > > > > Advantages for maintanance are obvious, plus, the feature seems easy to > > implement. What do you think? > > > > Deprication should not work like that. Deprication should be based on > versions, not actual dates. Basing it on dates like that can cause a number > of different problems for, and can even be considered disrespectful to, your > API's users. If/when you reach a point where you decide it's time for > something to be depricated, you should put out a new release. Even if you > have a way to know for certain that release will actually occur on-time, > then there would clearly be no problem in just waiting until that point to > put out a release that depricates the old stuff. Plus, that way you're not > rudely attempting to force the hand of your API user. If they're ok with > something being depricated, then they can upgrade to the newest version at > their own will, whevever *they* decide it's time for *them* to do so. I wasn't really thinking about library releases from a vendor. In these, deprecation should be version-based, as you say, so this feature wouldn't be used. I was thinking of cases where maintanance is often overlooked, say quick'n'dirty library modules -- there's no version, it's dumped into the same repository along with code referencing it. Often someone marks the previous API deprecated and but removing the code, getting collegaues to rewrite their code gets pushed in time forever, because there's always too little time to think about maintanance. Having a fixed date enforced by the compiler is not really rude then, it improves communication (people know whether they should hurry, it's all in ddoc and warnings) and serves as a reminder, for both the programmer and the library writter. Plus, if someone wants to "snooze" the maintanance wake up call, at least they have to do it consciously. Tomek
