At 01:30 PM 4/12/2004, Rick Byers wrote (in part)
>I really don't know what the best solution would be. Seems like someone
>should do some research on this using real-world scenarios. The one thing
>that is clear to me though is that the current behaviour (throwing away the
>original exception source) is definitely one of the more error-prone
>choices.
>
>Rick
I agree that it's a poor choice. There is a reasonable probability that whatever
caused the original (unhandled) exception has disrupted things to a moderate degree.
The fact that we're unwinding could potentially cause a number of objects to be in
unexpected states, and any finally blocks that make the assumption that the objects
being processed are not in unexpected states could thus fail.
Losing the original exception information (network error, disk full, etc) in order to
propagate the information about the more recent exception (that may have been caused
by bugs in code that [mis-]handles "premature unwinding") is not a good way to make it
easy to find the original problem.
IMO, it would make more sense to have the default behavior of a "finally" block be
that it captures the original exception, and has its own implied "try" block that
raises the original exception if there's an otherwise-unhandled exception within the
finally block. Something like
Exception origExc = null; // CLR magic does this
try {
...
}
catch(Exception newExc) { // CLR magic does this
origExc = newExc; // CLR magic does this
}
finally {
try { // CLR magic does this
...
} // CLR magic does this
catch(Exception newExc) { // CLR magic does this
raise (origExc = null) ? newExc : origExc; // CLR magic does this
} // CLR magic does this
But it's all quite complex -- suppose that a calling routine has a handler to handle
whatever exception is raised in the "finally" block (making the in-finally-block
exception into a handled exception)?
I'm one of the people who thinks that there should be very few try / catch blocks in
an application. try / finally for resource-leak-avoidance is a lot less necessary in
.NET than in the environment (Delphi) that was the "proving ground" for the .NET
exception mechanism.
J. Merrill / Analytical Software Corp
===================================
This list is hosted by DevelopMentorŪ http://www.develop.com
Some .NET courses you may be interested in:
NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles
http://www.develop.com/courses/gaspdotnetls
View archives and manage your subscription(s) at http://discuss.develop.com
