Root > Advanced topics > Using EurekaLog in DLL > Introduction > How DLLs report about failures

How DLLs report about failures

Previous pageReturn to chapter overviewNext page   

 

Important: as a general rule, you should write your application in a such way that it will behave correctly without EurekaLog on board. This means that if your or 3rd party code throws an exception in a DLL - it must be handled in a way that you expect. For example, by showing an error message, canceling action, retrying, etc. Once your application behaves like it is supposed to do - then you add EurekaLog for it. EurekaLog will auto-handle all unhandled exceptions automatically (by hooking few well-known places), and for everything else - you can call EurekaLog from your own handlers when needed. In other words:

Incorrect: your application does not show messages for exceptions (or do other things you want) from DLL and you are adding EurekaLog in hopes to fix this behavior;
Correct: your application correctly handles DLL exceptions and you are adding EurekaLog to receive reports about such exceptions.

 

Recall that object and class implementations are specific for programming language and compiler. I.e. a Delphi application doesn't know how to work with objects/classes from (for example) Microsoft C++ (and visa versa). This means that hi-level exception raised in DLL could not be properly handled by host application, unless both DLL and host are compiled by the same compiler and exception class uses the virtual destructor.

 

Also note that mixing OS and language exceptions within same module is confusing/problematic thing.

 

Therefore, APIs for DLLs usually do not use exceptions as a way to report errors. Instead: functions can use error codes - such as numeric codes, success/failure flags (booleans) and so on. There are de facto standard ways to report errors - provided by operating system (for example: GetLastResult, HRESULT - on Windows). However, 3rd party DLLs may use arbitrary error reporting method.

 

 

A simple example:

 

1. Incorrect (not recommended)

 

procedure DoSomething;
begin
  // Your payload
end;
 
exports
  DoSomething;

 

DoSomething function does not catch exceptions, and let exceptions escape to the caller module - which can be written in another programming language. This is a big NO - unless you compile both DLL and caller in the very same version of the compiler.

 

Note: if you develop DLL that will only be used in executable compiled in exactly the same version of the compiler, and you want to pass exceptions between modules for simplicity - see this article.

 

 

2. Correct (recommended)

 

procedure DoSomething;
begin
  try
    // Your payload
  except
    // Call EurekaLog to handle (process) exception
  end;
end;
 
exports
  DoSomething;

 

DoSomething function handles exceptions, thus exceptions are not escaped into the caller. See this article for sample code that may be placed inside except block.

 

Of course, you also want some way to tell the caller that there was an error when calling your function. See this article for more information. If you are developing your own DLL and API rules for it - see this article.

 

 

See also:




Send feedback... Build date: 2024-12-19
Last edited: 2024-07-08
PRIVACY STATEMENT
The documentation team uses the feedback submitted to improve the EurekaLog documentation. We do not use your e-mail address for any other purpose. We will remove your e-mail address from our system after the issue you are reporting has been resolved. While we are working to resolve this issue, we may send you an e-mail message to request more information about your feedback. After the issues have been addressed, we may send you an email message to let you know that your feedback has been addressed.


Permanent link to this article: https://www.eurekalog.com/help/eurekalog/dll_report_about_failures.php