Re: Try Finally...

From: VBDis (vbdis_at_aol.com)
Date: 11/01/04 

Date: 01 Nov 2004 01:32:28 GMT

Im Artikel <f06hd.4401$rh1.121110@news2.e.nsc.no>, "Bjørge Sæther"
<bjorge@hahaha_itte.no> schreibt:

>This is an interesting question. "What errors do we have to deal with ?" is
>an obvious one, but before answering this it may be relevant to ask for a
>list of error types weighted by "impact", "importance" or some possible
>criteria indicating where to start.

That's an interesting idea, too. Let me add another question
  "what errors can be handled where?"

We are used to structure our programs, into general actions, or tasks, that
afterwards are refined into sequences or repetitions of more specialized
subordinary actions. Now we can protect every more or less specialized action
with appropriate error handling, on every level of specialization. And we also
can identify and protect all local resources, that are used in a particular
action.

Now we do not only have to anwser "what errors can occur?", but also "what
action is affected?". We do not only have (non)continuable exceptions, but also
(non)continuable or (non)repeatable actions. Even if an error cannot be handled
(repaired) in a specific action, it may be possible to retry a more complex
action.

>>
- Hardware errors that may be corrected by the user while application is
running: "Re-insert floppy", "No response from modem", "Printer offline"
<<
Such errors can be handled in multiple levels. In the lowest level we ask the
user to correct the error situation, and then retry the interrupted action. If
the error persists, an error indication (exception or error code) has to be
generated, that may be handled in some higher level action.

>>
- Hardware errors that calls for a shutdown of both application and
computer: "Insufficient RAM size", etc..
- Errors indicating harware failure that calls for service - "disk failure",
etc.. OK with an informative message, but one should not expect to be able
to do much in such cases.
<<
Really not many choices here. The only decision is whether to abort the
program, or to let the user enter further commands in an interactive (GUI...)
application.

>>
- Application errors stemming from user errors: "Invalid date format",
etc...one should strive to handle this outside the regular exception
handling system, as a more friendly explaination is more appropriate. It is
not an "exception", IMHO.
<<
D'accord, invalid input can be simply rejected, until the user enters valid
information, or cancels the entire action.

>>
- Application errors caused by bugs and/or bad design
- Application errors caused by inappropriate configuration
- Application errors caused by inappropriate hardware, etc..
- Application errors caused by inappropriate data
...etc...
<<
In these cases, when no error recovery has been implemented yet, a detailed and
structured error log will be helpful. Every action level can log information
about the action in progress, and raise the same exception for more complete
logging. The result then is similar to a stack dump, not necessarily of the
physical call stack, but more informative of the logical action stack.

Depending on the robustness and modularity of an application it may be possible
to gracefully ignore or correct some errors, e.g. by skipping single invalid
data records, or by adjusting memory requirements (buffer sizes...), whereupon
the interrupted action can be retried, or can be skipped when inside a loop.
These chances for error recovery are not known in more specialized (lower
level) actions, that have no choice but to signal failure.

IMO this is just a good scenario for the demonstration of the use of SEH. In
every place where a reasonable decision can be made, how to proceed after an
error, an according exception handler can be inserted into the code. We can
assume that all required clean-up has been done when an error is cought here,
so that we are free to resume normal program operation, as soon as we know how
to proceed best. Unfortunately it may turn out then, after an analysis of an
error, that this particular error cannot be cured here, in this particular
action. Then the error handler can re-raise the same exception, for possible
handling in a more complex (or abstract) higher-level action.

SEH is not intended for error prevention, instead it's intended for a
comfortable error recovery. These are the more or less important benefits from
using SEH:
- safe clean-up even after an error occured (Finally)
- compact protection of multiple statements (Except)

While it might be possible to implement both aspects without SEH as well, the
according code would become very complicated, because checks for failed actions
have to be inserted all around the code. With SEH, in contrast, it's sufficient
to collect the resource protection code in Try-Finally blocks, and to wrap
possibly recoverable statement sequences into Try-Except blocks. Checks for
error situations are no more required in other locations, because in case of an
error that code will never execute.

The idea of resource protection IMO suggests to protect whole collections of
resources, as they are related to specific actions. All related resources can
be wrapped into records, that are passed to all involved subroutines. Then the
subroutines do not have to bother with the aquisition and finalization of the
resources, because this is handled in one Try-Finally block. Furthermore the
state of all these resources can be inspected in case of an error, increasing
the chances for appropriate error diagnosis and correction.

DoDi

Relevant Pages

  • Re: WinForms bug? ThreadException not invoked on Exceptions in system code pre-processing the me
    ... Message Queue and invoking the appropriate handler. ... if an Exception is raised during the PRE-PROCESSING of a Windows ... And because any handling will probably fail if there is no memory, the CLR will terminate the application without attempting to call the ApplicationException or UnhandledException events. ...
    (microsoft.public.dotnet.framework.windowsforms)
  • Re: BackgroungWork taske ended for no appearent reason
    ... To do the same thing with Try/Catch blocks requires wrapping every file access with a Do While ... ... If there was any exception thrown in your DoWork event handler, ... If the operation raises an exception that your code does not handle, ... Microsoft Online Community Support ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Frame-based exception handling problem on Server 2008
    ... In this case, the exception ends fatal, usually Cygwin creates a stack ... The Cygwin DLL is a POSIX ... handler is supposed to be *the* exception handler for Cygwin ... It also does not know if the signal handler returns or not. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Frame-based exception handling problem on Server 2008
    ... If I set a breakpoint to our exception ... points to the default handler, our exception handler is called just fine. ... typedef struct _exception_list ...
    (microsoft.public.win32.programmer.kernel)
  • got exceptions when I run "sql best Practice" tool.
    ... Cleaning up resources used by rule:Microsoft.SqlBpa.Rules.BpAllowUpdateEnabled.BPAllowUpdate ... Exception rethrown at: ... at Microsoft.BPA.Server.JobCoordinatorComponent.JobRunner.executeJob(NameValueCollection bpInputParams, BPASQLServerInfo sqlServer) ...
    (microsoft.public.sqlserver.tools)