Is there really any reason for the try keyword?  Seems to me that we can drop it.  But if we do that, then we can also attach catch blocks to any block, most interestingly function blocks, where you could chain exceptions like somebody mentioned recently:

void foo()
{
   // stuff
}
catch(Exception e)
{
    throw FooFailedException("foo() failed", e);
       // chains "foo() failed" onto the exception chain
}

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

Ack!  Just realized that my example has the MAJOR downside of concealing the exception type...all Exceptions become FooFailedExceptions.

Somehow, chaining of exceptions should retain the original exception type, IMHO.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

That sounds like a really great idea.  More flexible... less typing... one less keyword... it's great!

Sean

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3BEC19BB.D1D93828@deming-os.org...
> Is there really any reason for the try keyword?  Seems to me that we can drop it.  But if we do that, then we can also attach catch blocks to any block, most interestingly function blocks, where you could chain exceptions like somebody mentioned recently:
>
> void foo()
> {
>    // stuff
> }
> catch(Exception e)
> {
>     throw FooFailedException("foo() failed", e);
>        // chains "foo() failed" onto the exception chain
> }

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:9sh7p5$227v$1@digitaldaemon.com...

> That sounds like a really great idea.  More flexible... less typing... one less keyword... it's great!

This however adds additional job for the compiler of determining which blocks can potentionally throw exceptions and which can't, for optimization purposes I believe.

Other than that, I like the idea. Could really make the program look neater, and less typing as well... kewl =)

"Pavel "EvilOne" Minayev" <evilone@omen.ru> wrote in message news:9sil27$85b$1@digitaldaemon.com...
> "Sean L. Palmer" <spalmer@iname.com> wrote in message news:9sh7p5$227v$1@digitaldaemon.com...
>
> > That sounds like a really great idea.  More flexible... less typing...
one
> > less keyword... it's great!
>
> This however adds additional job for the compiler of determining which blocks can potentionally throw exceptions and which can't, for optimization purposes I believe.
>
> Other than that, I like the idea. Could really make the program look neater, and less typing as well... kewl =)


It does look like the try keyword is redundant. On the other hand, some redundancy is useful for:

1) catching syntax errors
2) putting out a reasonable error message as to what might be wrong
3) making it easier for a person examining the code to understand the intent
of it

Consider this - if a language had no redundancy in it, then *any* random sequence of characters is a valid program.

How much redundancy is just right is a matter of personal taste. I, for instance, find Pascal to be unbearably wordy, and Java excessively wordy. D will take its cues from C and C++ on the general style of wordiness.

Pavel \"EvilOne\" Minayev wrote:

> "Sean L. Palmer" <spalmer@iname.com> wrote in message news:9sh7p5$227v$1@digitaldaemon.com...
>
> > That sounds like a really great idea.  More flexible... less typing... one less keyword... it's great!
>
> This however adds additional job for the compiler of determining which blocks can potentionally throw exceptions and which can't, for optimization purposes I believe.

As I understand it, the parser determines which blocks are caught blocks and which are not.  You just change the parser definition file; removing try would not affect the compiler itself at all.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

Along the same lines, can we remove the requirement of having {} around the try blocks?  This seems reasonable to me:

foo()  // note that there is no trailing semicolon
    catch(ACertainException e)
    {
         bar();
     };  // this is the closing semicolon of the expression

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

Walter wrote:

> It does look like the try keyword is redundant. On the other hand, some redundancy is useful for:
>
> 1) catching syntax errors
> 2) putting out a reasonable error message as to what might be wrong
> 3) making it easier for a person examining the code to understand the intent
> of it
>
> Consider this - if a language had no redundancy in it, then *any* random sequence of characters is a valid program.
>
> How much redundancy is just right is a matter of personal taste. I, for instance, find Pascal to be unbearably wordy, and Java excessively wordy. D will take its cues from C and C++ on the general style of wordiness.

Fair points.  Frankly, I don't know whether try is a practical help or not.  I would still lean toward removing it, but that's just my opinion.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3BEFE4A2.C1B4968F@deming-os.org...
> Along the same lines, can we remove the requirement of having {} around
the
> try blocks?  This seems reasonable to me:
>
> foo()  // note that there is no trailing semicolon
>     catch(ACertainException e)
>     {
>          bar();
>      };  // this is the closing semicolon of the expression

I suggested a similar thing not long ago. Walter's reply wasn't that clear. =)

I don't understand why people want to be able to write unclear programs so much.  What is wrong with try { }?  Really, one should have to make a good argument why NOT to force clarity, instead of having to argue for clarity in the first place.  All these "features" make compilation, analysis, and debugging harder.

Aaron

Pavel \"EvilOne\" Minayev wrote:
> 
> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3BEFE4A2.C1B4968F@deming-os.org...
> > Along the same lines, can we remove the requirement of having {} around
> the
> > try blocks?  This seems reasonable to me:
> >
> > foo()  // note that there is no trailing semicolon
> >     catch(ACertainException e)
> >     {
> >          bar();
> >      };  // this is the closing semicolon of the expression
> 
> I suggested a similar thing not long ago. Walter's reply wasn't that clear. =)