Re: Try Finally...

From: VBDis (vbdis_at_aol.com)
Date: 10/26/04 

Date: 26 Oct 2004 21:27:42 GMT

Im Artikel <417e1ea5$0$37789$e4fe514c@news.xs4all.nl>, "Maarten Wiltink"
<maarten@kittensandcats.net> schreibt:

>As an opening, I think there should be no retrying from a finally clause
>at all. As Rob(?) said, a finally clause should ideally not even know if
>an exception occurred or not. If one did, retrying should jump back to
>the offending instruction; without one, it should do nothing. Not only
>because there is nothing to retry, but it would cause an infinite loop.

This is one of the BASIC features I learned to love in the past, with Resume,
Resume Next or Resume <label>. But once I found the according code in .NET
MSIL, I saw that the cost is very high for such comfort. The implementation
requires a line table, linking line numbers to code addresses, and an
Inc(LineNo) or LineNo:=nnn at the begin of every line; the further code in the
exception handler is quite lengthy, and I suspect that the .NET MSIL Filter
instruction was introduced for the sole purpose of enabling exception handling
in the BASIC OnError way, instead of SEH. AFAIR the Filter code can not only
access the exception record and signal handled/unhandled, but it also can
specify which exception handler (Resume, ResumeNext...) to use. I had to
consult the MSIL specs and my old disassemblies of the according code, if
anybody is interested in more accurate informations.

>That casts a new light on things. If code that caused an exception can
>be retried, you do indeed need to follow the handler chain first and
>only unwind the stack later, if and when you decided that you're not
>going to retry.

In BASIC the retry starts at the line in that subroutine that implements the
handler, not at the line that really caused the exception. IMO this is a wise
decision, allowing for modifications of the context (i.e. shrink buffer size or
select a different method...), before starting an retry. And since the stack is
unwound before the retry, the application code must not be reentrant; I hope
you know what this means...

DoDi

Relevant Pages

  • Re: Try Finally...
    ... Now we can protect every more or less specialized action ... an error indication (exception or error code) has to be ... an according exception handler can be inserted into the code. ... resources, as they are related to specific actions. ...
    (comp.lang.pascal.delphi.misc)
  • 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)