Re: Try Finally...

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

Date: Thu, 28 Oct 2004 11:44:36 -0500

VBDis wrote:
> Im Artikel <2u8158F2706ubU1@uni-berlin.de>, Rob Kennedy <me3@privacy.net>
> schreibt:
>> (Delphi's try-finally blocks still execute, though.)
>
> In my tests (D4) no Finally code was executed, the call to @Assert actually
> never returned and ended up in Halt instead, without triggering any Finally
> code. I.e. SEH is not working at all when the various exception conditions do
> not trigger the Delphi exception handling.

No no. You misunderstood. In your non-SysUtils code, there were *no*
exceptions at all. No system exceptions, and no Delphi exceptions.
Execution proceeded directly to Halt. Since there were no exceptions, no
finally block could execute.

When I said that try-finally blocks still execute, I was talking about
the case when a system exception occurs, such as division by 0 or access
violation. Assertion failures aren't system exceptions. (And they aren't
Delphi exceptions, either, unless SysUtils is included.)

> P.S.: @Assert shows another calling convention encoding, in addition to the
> (stdcall? cdecl?) convention with _GetMem.

Delphi's procedure names don't suggest a calling convention. Neither do
C's, for that matter. In C, it's the other way around: The calling
convention suggests the name. The compiler won't guess the calling
convention based on the name, but it will mangle a name based on the
calling convention.

Many procedures in System.pas are declared without parameters and are
declared using the default register calling convention. They lack
parameters because when recompiling that unit, the compiler may add
automatic prologue and epilogue code that is inappropriate for those
methods. Delphi never adds that extra code to register procedures that
have no parameters. The parameters don't need to be mentioned in the
source, though, because the compiler doesn't need to read them from the
source file when it compiles other units. Instead, the procedure syntax
is built in to the compiler, and so the compiler always knows how to
generate calls to them with the right parameters.

Many of System.pas's internal procedures don't use any predefined
calling convention. Instead, other code might use JMP insetad of CALL to
go directly to the internal routine. Or it might bend the rules on
saving and restoring registers so it can return values in, say, EBX
instead of EAX. 

-- 
Rob

Relevant Pages

  • Re: Benefits of Dynamic Typing
    ... >> - On the toplevel of the compiler, to report all compile errors found ... > Catching and reporting all exceptions in the toplevel doesn't require ... Note that I don't use exceptions much. ... exception for reporting an end of file though. ...
    (comp.lang.functional)
  • Re: Handling error/status messages by interface to C++ programs
    ... about how to design a compiler, please tell me where I can find ... exceptions for managing the error detection is rather a bad idea. ... I have to say I have seen a simple example of an object-oriented parser design in some book (unfortunately I forgot ... It would trigger user notification and do recover housekeeping like reseting the current syntax row's token stack because one wants to continue parsing and detect any other errors w/o aborting. ...
    (comp.object)
  • Re: Cpp Considered Harmful
    ... programming language, the compiler, the IDE, the libraries, etc. ... WRT exceptions, the fact of the matter is that placing certain ... >> regarding the CPP. ...
    (comp.lang.cpp)
  • Re: Fortran Error Reporting Requirements (Was: GFORTRAN PROBLEM WITH SAVE STATEMENT)
    ... If you ever had a compiler that failed to diagnose this, ... to trap exceptions. ... Reporting of violations of syntax rules and constraints is required in section 1.7.3. ... Most of the detection and reporting requirements are in section 1.5, ...
    (comp.lang.fortran)
  • Re: Benefits of Dynamic Typing
    ... an extendible type hierarchy. ... which means "the compiler found a fatal error and it cannot continue compiling this module, so we return to compiler's toplevel code and print errors found so far before exiting". ... in a type hierarchy, so that doesn't decide the point in question. ... Actually I think it promotes nonlocal dependencies, because exceptions tend to expose local information to an entirely different abstraction layer. ...
    (comp.lang.functional)