Re: Try Finally...

From: Rob Kennedy (me3_at_privacy.net)
Date: 10/27/04 

Date: Tue, 26 Oct 2004 17:25:05 -0500

VBDis wrote:
> try
> assert(False, 'test exception');
> finally
> WriteLn('don't want to handle exceptions');
> end;
> [...]
> Okay, after an test with D4 I understand your complaint that without the
> inclusion of SysUtils the first version aborts immediately, without executing
> the Finally code. But since the code takes no means to prevent an abort at all,
> this seems to be the shortest way to do exactly what the code means: abort on
> any exception. Short also in code size, 23KB less due to not including
> SysUtils.

That code actually involves no exceptions at all. System.Assert tries to
call System.AssertProc to create an exception. If that function pointer
isn't assigned, then it jumps into System.Error and tries to call
System.ErrorProc instead. If that variable isn't assigned either, then
it just calls Halt with an error code of reAssertionFailed (21). The
documentation doesn't mention this.

System.Assert can't raise an EAssertionFailed exception without having a
definition for that class. That class is defined in SysUtils. So Assert
can't raise that exception without SysUtils. SysUtils assigns procedures
to both AssertProc and ErrorProc. AssertProc is what creates and raises
the EAssertionFailure object.

You could define your own EAssertionFailure class and create it in your
own AssertProc procedure, which you assign when your program starts up.

> So let me rephrase your complaint about Delphi SEH. It should not read:
> Finally causes a program to abort.
> Instead it should read:
> Except does not prevent a program from aborting, if SysUtils is not used.

If SysUtils is not used, then system exceptions are not transformed into
Delphi exceptions, and so Delphi's try-except blocks don't handle them.
(Delphi's try-finally blocks still execute, though.) 

-- 
Rob

Relevant Pages

  • Re: Try Finally...
    ... assert(False, 'test exception'); ... But since the code takes no means to prevent an abort at all, ... But as soon as any unit in the project uses SysUtils, ... More annyoing, and really unexpected to any Delphi user, is the behaviour of ...
    (comp.lang.pascal.delphi.misc)
  • Re: Oh boy, how did we miss this...
    ... >the passage which clearly stated that SysUtils is required for SEH. ... "Raising an exception in the initialization section of a unit may not produce ... Note please this is specific to unit initialization and finalization. ...
    (comp.lang.pascal.delphi.misc)
  • Re: Try Finally...
    ... Then there must be another reason for not wanting the sysutils unit ... What they won't know is that their exception ... > to the next handler. ... "Fix some registers" ?? ...
    (comp.lang.pascal.delphi.misc)
  • Re: Oh boy, how did we miss this...
    ... >> the passage which clearly stated that SysUtils is required for SEH. ... I'm still curious to know what your exception handlers did. ... > Note please this is specific to unit initialization and finalization. ... Except where it tells you that exception support comes from SysUtils. ...
    (comp.lang.pascal.delphi.misc)
  • Re: Exception Handling...
    ... >making something new for each exception block it encounters. ... >compiler how to do the exception-filtering actions that the RTL does. ... code it uses HandleAnyException and when you use the "On ExceptionObject Do" ... since all the necessary code is already in SysUtils, ...
    (comp.lang.pascal.delphi.misc)