www.digitalmars.com         C & C++   DMDScript  

D - Error Handling

reply Richard Burk <sfentress home.com> writes:
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
Aug 16 2001
parent reply "Walter" <walter digitalmars.com> writes:
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

Aug 16 2001
parent reply Richard Burk <rburk ibasis.net> writes:
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


Aug 16 2001
parent reply "Walter" <walter digitalmars.com> writes:
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



Aug 20 2001
parent reply "Sean L. Palmer" <spalmer iname.com> writes:
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




Oct 23 2001
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
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))) ]
Oct 23 2001
parent reply "Sean L. Palmer" <spalmer iname.com> writes:
"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

 to continue into the catch and finally blocks.  It's not "pure" C-style,

 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,

 Very Bad Thing.  If you want to pass the variables into another stack

 pass pointers to them as function arguments or some such.  Otherwise, we

 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
Oct 24 2001
parent "Walter" <walter digitalmars.com> writes:
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?).
Oct 25 2001