For error handling why not provide something like the following enhancement...

try
{
  ...
}
catch(SomeException e) handleSomeException(e);
finally
{
}

What I am showing here is that the handleSomeException(e)
is a method call with the SomeException e as its lone
parameter.  e is much more than just the exception.  It contains
the scope of the try block which raised the exception.  e would
reference have a reference to the current class via e.this.  e
would have reference to all variables defined in the scope of
the try block.  The reasoning for this is that many times the
exception handling code can be reused by multiple methods.
Since exception handling does not have to be performance
intensive as already pointed out in the specification, calling a
method to handle the exception would be fine.  This would
allow for more readable code without the exception handling
code to make the normal program flow code cluttered.  Since
the method would be dedicated to handling the error it could
potentially be tested more easily via unit test calling it directly.
This would improve the reliability of the error handling routine
because its functionality could be more easily verified
independently of the method that invokes it.  The finally block
would still exist or perhaps it could have a method call defined
for it, but my experience with the try/catch/finally is that the
catch statement should be a method to allow for independent
verification and validation of the error handling routine.
The hard part has been supplying the scope of the variables
because any variables defined within the scope of the try
block aren't available.  That is why e would have the scope
of the try block because it is produced by the try block.

Richard Burk

I'm sorry, I do not understand. I'm not at all sure how access to local variables in some other stack frame would help. -Walter

"Richard Burk" <sfentress@home.com> wrote in message news:3B7C0D9A.46873947@home.com...
> For error handling why not provide something like the following enhancement...
>
> try
> {
>   ...
> }
> catch(SomeException e) handleSomeException(e);
> finally
> {
> }
>
> What I am showing here is that the handleSomeException(e)
> is a method call with the SomeException e as its lone
> parameter.  e is much more than just the exception.  It contains
> the scope of the try block which raised the exception.  e would
> reference have a reference to the current class via e.this.  e
> would have reference to all variables defined in the scope of
> the try block.  The reasoning for this is that many times the
> exception handling code can be reused by multiple methods.
> Since exception handling does not have to be performance
> intensive as already pointed out in the specification, calling a
> method to handle the exception would be fine.  This would
> allow for more readable code without the exception handling
> code to make the normal program flow code cluttered.  Since
> the method would be dedicated to handling the error it could
> potentially be tested more easily via unit test calling it directly.
> This would improve the reliability of the error handling routine
> because its functionality could be more easily verified
> independently of the method that invokes it.  The finally block
> would still exist or perhaps it could have a method call defined
> for it, but my experience with the try/catch/finally is that the
> catch statement should be a method to allow for independent
> verification and validation of the error handling routine.
> The hard part has been supplying the scope of the variables
> because any variables defined within the scope of the try
> block aren't available.  That is why e would have the scope
> of the try block because it is produced by the try block.
>
> Richard Burk
>

Consider the catch statement as in the same scope as inside the try
block.  That way any variables defined within the try block are
accessible to the catch statement.  Giving the exception the ability
to access the variables from the try block to log them on an
exception in pretty powerful stuff.  For instance I would like to
not write a log statement to output the values of variables within
the try block, but if an exception occurs then I would like the
catch statement to output those values.  However if the variables
happen to be declared within the try block then I do not have
access to those variables as they are out of scope.  If the exception
has reference to them or to copies (! - this may be better) of them
then they can be outputted via log statements.  By doing this the
normal executing code would not have to worry about performance
being hindered by log statements.  The exception would have log
statements.  At this point the exception doesn't worry about
performance.  Does that help?

Richard Burk

Walter wrote:

> I'm sorry, I do not understand. I'm not at all sure how access to local variables in some other stack frame would help. -Walter
>
> "Richard Burk" <sfentress@home.com> wrote in message news:3B7C0D9A.46873947@home.com...
> > For error handling why not provide something like the following enhancement...
> >
> > try
> > {
> >   ...
> > }
> > catch(SomeException e) handleSomeException(e);
> > finally
> > {
> > }
> >
> > What I am showing here is that the handleSomeException(e)
> > is a method call with the SomeException e as its lone
> > parameter.  e is much more than just the exception.  It contains
> > the scope of the try block which raised the exception.  e would
> > reference have a reference to the current class via e.this.  e
> > would have reference to all variables defined in the scope of
> > the try block.  The reasoning for this is that many times the
> > exception handling code can be reused by multiple methods.
> > Since exception handling does not have to be performance
> > intensive as already pointed out in the specification, calling a
> > method to handle the exception would be fine.  This would
> > allow for more readable code without the exception handling
> > code to make the normal program flow code cluttered.  Since
> > the method would be dedicated to handling the error it could
> > potentially be tested more easily via unit test calling it directly.
> > This would improve the reliability of the error handling routine
> > because its functionality could be more easily verified
> > independently of the method that invokes it.  The finally block
> > would still exist or perhaps it could have a method call defined
> > for it, but my experience with the try/catch/finally is that the
> > catch statement should be a method to allow for independent
> > verification and validation of the error handling routine.
> > The hard part has been supplying the scope of the variables
> > because any variables defined within the scope of the try
> > block aren't available.  That is why e would have the scope
> > of the try block because it is produced by the try block.
> >
> > Richard Burk
> >

Ok, I understand what you mean now. But I think that the try block should handle its own errors if access to its local variables is important.


Richard Burk wrote in message <3B7C1761.ED86F8EF@ibasis.net>...
>Consider the catch statement as in the same scope as inside the try
>block.  That way any variables defined within the try block are
>accessible to the catch statement.  Giving the exception the ability
>to access the variables from the try block to log them on an
>exception in pretty powerful stuff.  For instance I would like to
>not write a log statement to output the values of variables within
>the try block, but if an exception occurs then I would like the
>catch statement to output those values.  However if the variables
>happen to be declared within the try block then I do not have
>access to those variables as they are out of scope.  If the exception
>has reference to them or to copies (! - this may be better) of them
>then they can be outputted via log statements.  By doing this the
>normal executing code would not have to worry about performance
>being hindered by log statements.  The exception would have log
>statements.  At this point the exception doesn't worry about
>performance.  Does that help?
>
>Richard Burk
>
>Walter wrote:
>
>> I'm sorry, I do not understand. I'm not at all sure how access to local variables in some other stack frame would help. -Walter
>>
>> "Richard Burk" <sfentress@home.com> wrote in message news:3B7C0D9A.46873947@home.com...
>> > For error handling why not provide something like the following enhancement...
>> >
>> > try
>> > {
>> >   ...
>> > }
>> > catch(SomeException e) handleSomeException(e);
>> > finally
>> > {
>> > }
>> >
>> > What I am showing here is that the handleSomeException(e)
>> > is a method call with the SomeException e as its lone
>> > parameter.  e is much more than just the exception.  It contains
>> > the scope of the try block which raised the exception.  e would
>> > reference have a reference to the current class via e.this.  e
>> > would have reference to all variables defined in the scope of
>> > the try block.  The reasoning for this is that many times the
>> > exception handling code can be reused by multiple methods.
>> > Since exception handling does not have to be performance
>> > intensive as already pointed out in the specification, calling a
>> > method to handle the exception would be fine.  This would
>> > allow for more readable code without the exception handling
>> > code to make the normal program flow code cluttered.  Since
>> > the method would be dedicated to handling the error it could
>> > potentially be tested more easily via unit test calling it directly.
>> > This would improve the reliability of the error handling routine
>> > because its functionality could be more easily verified
>> > independently of the method that invokes it.  The finally block
>> > would still exist or perhaps it could have a method call defined
>> > for it, but my experience with the try/catch/finally is that the
>> > catch statement should be a method to allow for independent
>> > verification and validation of the error handling routine.
>> > The hard part has been supplying the scope of the variables
>> > because any variables defined within the scope of the try
>> > block aren't available.  That is why e would have the scope
>> > of the try block because it is produced by the try block.
>> >
>> > Richard Burk
>> >
>

What he's saying is that he wants the entire try...catch... finally statement to have one big scope.  I think.  I can see how that'd be useful.

Perhaps you could think of it like this, Walter: (notice the curly braces)

try
{
  int* pint = new int(5);
  DoSomethingThatMightThrow();

  catch(SomeException e)
  {
    handleSomeException(e);
  }
  finally
  {
    delete pint;
  }
}

Since the try doesn't really finish until you reach the end of the finally clause.  Keeps people from having to move their variables out of the try block so they can be accessed from the finally block.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:9lscqd$1dsj$2@digitaldaemon.com...
> Ok, I understand what you mean now. But I think that the try block should handle its own errors if access to its local variables is important.
>
>
> Richard Burk wrote in message <3B7C1761.ED86F8EF@ibasis.net>...
> >Consider the catch statement as in the same scope as inside the try
> >block.  That way any variables defined within the try block are
> >accessible to the catch statement.  Giving the exception the ability
> >to access the variables from the try block to log them on an
> >exception in pretty powerful stuff.  For instance I would like to
> >not write a log statement to output the values of variables within
> >the try block, but if an exception occurs then I would like the
> >catch statement to output those values.  However if the variables
> >happen to be declared within the try block then I do not have
> >access to those variables as they are out of scope.  If the exception
> >has reference to them or to copies (! - this may be better) of them
> >then they can be outputted via log statements.  By doing this the
> >normal executing code would not have to worry about performance
> >being hindered by log statements.  The exception would have log
> >statements.  At this point the exception doesn't worry about
> >performance.  Does that help?
> >
> >Richard Burk
> >
> >Walter wrote:
> >
> >> I'm sorry, I do not understand. I'm not at all sure how access to local variables in some other stack frame would help. -Walter
> >>
> >> "Richard Burk" <sfentress@home.com> wrote in message news:3B7C0D9A.46873947@home.com...
> >> > For error handling why not provide something like the following enhancement...
> >> >
> >> > try
> >> > {
> >> >   ...
> >> > }
> >> > catch(SomeException e) handleSomeException(e);
> >> > finally
> >> > {
> >> > }
> >> >
> >> > What I am showing here is that the handleSomeException(e)
> >> > is a method call with the SomeException e as its lone
> >> > parameter.  e is much more than just the exception.  It contains
> >> > the scope of the try block which raised the exception.  e would
> >> > reference have a reference to the current class via e.this.  e
> >> > would have reference to all variables defined in the scope of
> >> > the try block.  The reasoning for this is that many times the
> >> > exception handling code can be reused by multiple methods.
> >> > Since exception handling does not have to be performance
> >> > intensive as already pointed out in the specification, calling a
> >> > method to handle the exception would be fine.  This would
> >> > allow for more readable code without the exception handling
> >> > code to make the normal program flow code cluttered.  Since
> >> > the method would be dedicated to handling the error it could
> >> > potentially be tested more easily via unit test calling it directly.
> >> > This would improve the reliability of the error handling routine
> >> > because its functionality could be more easily verified
> >> > independently of the method that invokes it.  The finally block
> >> > would still exist or perhaps it could have a method call defined
> >> > for it, but my experience with the try/catch/finally is that the
> >> > catch statement should be a method to allow for independent
> >> > verification and validation of the error handling routine.
> >> > The hard part has been supplying the scope of the variables
> >> > because any variables defined within the scope of the try
> >> > block aren't available.  That is why e would have the scope
> >> > of the try block because it is produced by the try block.
> >> >
> >> > Richard Burk
> >> >
> >
>
>

Sean, I agree that it makes sense to have the scope of variables in a try-block to continue into the catch and finally blocks.  It's not "pure" C-style, though, which might just make it confusing and therefore counterproductive...

However, I think that Richard's original idea was to have the scope of the variables extend into some function that the exception called.  This, IMHO, is a Very Bad Thing.  If you want to pass the variables into another stack frame, pass pointers to them as function arguments or some such.  Otherwise, we are doing some really weird things to the scoping rules.

--
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:3BD586EA.D6147D23@deming-os.org...
> Sean, I agree that it makes sense to have the scope of variables in a
try-block
> to continue into the catch and finally blocks.  It's not "pure" C-style,
though,
> which might just make it confusing and therefore counterproductive...

Not a big deal for me either way.  I can move my variables out of the try block no problem.  ;)

> However, I think that Richard's original idea was to have the scope of the variables extend into some function that the exception called.  This,
IMHO, is a
> Very Bad Thing.  If you want to pass the variables into another stack
frame,
> pass pointers to them as function arguments or some such.  Otherwise, we
are
> doing some really weird things to the scoping rules.

No doubt, I'd be against that too I think unless it was useful, safe, and easy to implement; it seems to be none of the three.  I'd rather have the language spec be simple more than just about anything else.

Sean

Sean L. Palmer wrote in message <9r5reg$1ue2$1@digitaldaemon.com>...
>No doubt, I'd be against that too I think unless it was useful, safe, and easy to implement; it seems to be none of the three.  I'd rather have the language spec be simple more than just about anything else.


Yes, I'm trying for a small set of simple rules for which powerful programs can be created. Sort of like DNA has 4 rules, and look what it's capable of! Ok, that's a hyperbolic example.

The rules for C++ templates, however, are simple looking but actually are extremely complicated with many, many interaction special rules with the rest of the language (for example, when is a > a greater than and when does it close a template argument list?).