CODEWITHSUNDEEP
delphidllexception
jpfollenius
jpfollenius

Reputation: 16602

Exceptions and DLL in Delphi

What is the right way to handle exceptions thrown from inside a DLL in Delphi?

Something like this

on E : ESomeException do ...

or

if (E is ESomeException) then ...

fails, because of the separate type registries of the DLL and the main application.

Upvotes: 8

Views: 5410

Answers (5)

yonojoy
yonojoy

Reputation: 5566

I think, it is agreed on that exceptions should never be allowed to escape from the DLL.

But sometimes you do not have control over a DLL and cannot avoid having trouble with exceptions.

We, for instance, had a problem with a function in an external DLL that was blocked by AV software settings ("ransomware protection") leading to access violations in Delphi.

The following code is working for us:

var
    O: TObject;
    Msg: AnsiString;   //type depending on DLL
begin
    try
        CallExternalDll(...);
    except
        //on E: Exception do might lead to access violations
        //because the exception might not be of type Exception
        O := ExceptObject;
        //Depending on the DLL this or an other cast might 
        //or might not be necessary:
        Msg := PAnsiChar(Exception(O).Message);

        raise Exception.Create(Msg);
    end;
end;

Upvotes: 0

Jeroen Wiert Pluimers
Jeroen Wiert Pluimers

Reputation: 24463

For pure DLL's exceptions are not allowed to cross the DLL boundary (like Deltics mentions) - no matter what language.

You get all sorts of trouble there, especially because you don't know which language, RTL, memory manager, etc, is on each side of the boundary.

So you are back to the classic error handling paradigm:

Instead of DLL's, you could use BPL packages (as Lars suggested): there you know that both sides will use the same RTL and memory manager.

Both packages and BPL usually give you a versioning nightmare anyway (too many degrees of freedom).

A more rigorous solution is to go for a monolithic executable; this solves both problems:

  • much easier versioning
  • guaranteed only one RTL and memory manager

--jeroen

PS: I've made this an additional answer because that allows for easier pasting of links.

Upvotes: 10

Lars Truijens
Lars Truijens

Reputation: 43602

If you use runtime packages (at least rtlxx.bpl) for both your application and your dll, then both have the same type and it will work. Of course this limits the use of your dll to Delphi/BCB only.

Another solution is not using exceptions at all like Deltics suggest. Return error codes.

Or use COM. Then you can have exceptions and not limit your dll to Delphi only.

Upvotes: 3

jpfollenius
jpfollenius

Reputation: 16602

This workaround seems to do it for me:

 function ExceptionMatch (Exc : Exception; ExcClass : TClass) : Boolean;

 var
    CurrClass           : TClass;

  begin
  CurrClass := Exc.ClassType;
  while (CurrClass <> nil) do
    begin
    if SameText (CurrClass.ClassName, ExcClass.ClassName) then
      Exit (True);
    CurrClass := CurrClass.ClassParent;
    end;
  Result := False;
  end;

I'm prepared for you to destroy this :)

What is wrong with this approach? What is potentially dangerous?

Upvotes: -3

Deltics
Deltics

Reputation: 23036

The safest way is to not allow exceptions to "escape" from the DLL in the first place.

But if you have no control over the source of DLL and are therefore unable to ensure this, you can still test the exception class name:

if SameText(E.ClassName, 'ESomeException') then ...

Upvotes: 5

Related Questions