D - Error Handling
- Richard Burk (37/37) Aug 16 2001 For error handling why not provide something like the following
- Walter (4/41) Aug 16 2001 I'm sorry, I do not understand. I'm not at all sure how access to local
- Richard Burk (18/63) Aug 16 2001 Consider the catch statement as in the same scope as inside the try
- Walter (3/67) Aug 20 2001 Ok, I understand what you mean now. But I think that the try block shoul...
- Sean L. Palmer (22/93) Oct 23 2001 What he's saying is that he wants the entire try...catch... finally
- Russ Lewis (13/13) Oct 23 2001 Sean, I agree that it makes sense to have the scope of variables in a tr...
- Sean L. Palmer (13/21) Oct 24 2001 try-block
- Walter (8/11) Oct 25 2001 Yes, I'm trying for a small set of simple rules for which powerful progr...
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
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
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
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
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
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
"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 atry-blockto 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 aVery Bad Thing. If you want to pass the variables into another stackframe,pass pointers to them as function arguments or some such. Otherwise, wearedoing 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
"Walter" <walter digitalmars.com> 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