mORMot Open Source

Anyway, it's a bug in the framework and I would like it fixed.
I find it in the documentation about leaked exceptions, but as mere recommendation.

16.8.1. Error handling

This is why exceptions should better be intercepted on the server side, with a try .. except block within the service methods, then converted into low level DTO types, specific to the service, then explicitly transmitted as error codes to the client.

The first rule is that raising exception should be exceptional - as its name states: exceptional. I mean, service code should not raise an exception in normal execution, even in case of wrong input

But I found these snippets presenting launching exception from user services as *FRAMEWORK FEATURE*:

14.9. Handling errors

When using Ctxt.Input*[] properties, any missing parameter will raise an EParsingException. ***It will therefore be intercepted by the server process (as any other exception), and returned to the client with an error message containing the Exception class name and its associated message***.
::::
***Note that the framework core will catch any exception during the method execution, and will return a "Internal Server Error" / HTTP_SERVERERROR = 500 error code with the associated textual exception details.***

16.6.4. Enhanced sample: remote SQL access
::::
procedure TServiceRemoteSQL.Connect(aEngine: TRemoteSQLEngine;
::::
begin
  if fProps<>nil then
    raise Exception.Create('Connect called more than once'); <<<<< one of many "unOfficial" leaked exceptions showed in documentation
  fProps := TYPES[aEngine].Create(aServerName,aDatabaseName,aUserID,aPassWord);
end;
::::
***Any exception during SynDB.pas process, ***or raised manually*** in case of wrong use case will be transmitted to the client, just as expected.***

16.8.1. Error handling

Usually, in Delphi applications (like in most high-level languages), errors are handled via exceptions. By default, any Exception raised on the server side, within an interface-based service method, will be intercepted, and transmitted as an HTTP error to the client side, then a safe but somewhat obfuscated EInterfaceFactoryException will be raised, containing additional information serialized as JSON.

25.2.4. Exception handling

Of course, this logging mechanism is able to intercept the raise of exceptions, ***including the worse (e.g. EAccessViolation), to be logged automatically in the log file***, as such:

---------------------
I suspect that this error does not occur in 32 bit. I will test and post the results here as soon as I have time.
Anyway your workaround is acceptable and is the pattern used in languages that do not have exception handling such as "ANSI C", Oberon and "Go".

Thank you for your quick response
PS: Sorry I'm such a boring and nosy guy...