How to handle EInterfaceFactoryException properly

ASiwon · 2015-04-09 10:06:08

Hello,

from time to time during remote function call I have received an exception:

TInterfacedObjectFakeClient.FakeCall(IBkWazeniaImportyPodstaw.Podstaw) failed: '{
"errorCode":500,
"error":
{"ESQLDBOracle":{
"ClassName":"ESQLDBOracle",
"Address":"7FA52510",
"Statement": {
"ClassName":"TFreedObject",
"Address":"7FADBE10"
},
"Message": "TSQLDBOracleStatement error: ORA-00001: unique constraint (U_EKS.I_WP_NR_WAGONU) violated\nORA-06512: at \"U_EKS.P_WAGONY_OBECNE_DODAJ\", line 585\nORA-06512: at \"U_EKS.P_WAGONY_OBECNE_DODAJ\", line 322\nORA-06512: at \"U_EKS.SP_WAGONY_OBECNE_INSERT\", line 139\nORA-06512: at line 2"
}}
}'

And thats right. It is database index violation and it could sometimes happens. But how to handle this exception properly? I don't want to show whole exception message to the end user. Is it possible to easilly parse exception message in any way and get detailed information about raised exception? Or maybe this exception should be handled on server side and propagated in other way than exception EInterfaceFactoryException?

ab · 2015-04-09 11:26:09

Yes, such exceptions should better be handled on the server side.

Try to use a try .... except .... block in your interface implementation.

ASiwon · 2015-04-12 13:00:12

Ok - I will use try except in interface implementation because propagate Oracle's or any other database exception it is a bad idea. Even if I will change Oracle exception to my own exception it will be still problem with reading exception details on client side. But mORMot's client-server exception handling is great and I still want to use it.

Now exception stucture is serialized to the JSON format but after that some prefixes are added for example ErrorCode or Error information. Now it is impossible to directly parse exception message and get detailed information about occured exception. Now I'm removing some parts of message and then I'm deserializing structure to exception on client side. It works but it is hand made method.

I think it would be better if exception message could be in pure JSON format. Then it would be much more simpler to deserialize detailed information about exception end use it on client side. What do you think about it?

Last edited by ASiwon (2015-04-12 13:00:48)

ab · 2015-04-12 13:33:13

Exceptions are not value objects, but true class instances, with some methods, and a specific behavior within the Delphi language.
A Delphi exception is something very specific, and would not be easily converted into e.g. a JavaScript, Java or C# exception.
As such, they are not good candidate on serialization, and transmission per value, from the server side to the client side.

So we would NOT be in favor of propagating exceptions to the client side.
And just one exception message (i.e. a string) may be not versatile enough.
Sometimes, you need additional structured information.

This is why exceptions should better be interfaced on the server side, then converted into low level DTO types, specific to the service, then explicitly transmitted as error codes to the client.
For instance, you may use an enumerate, in conjunction with a variant for additional structured information (as a string or a more complex TDocVariant), to transmit an error to the client side.
See how ICQRSQuery is defined in mORMotDDD.pas.

I've just updated the documentation, and written a blog article about this point.

ASiwon · 2015-04-12 15:07:18

Thank you very much for answer.

Exceptions are not value objects, but true class instances, with some methods, and a specific behavior within the Delphi language.
A Delphi exception is something very specific, and would not be easily converted into e.g. a JavaScript, Java or C# exception.
As such, they are not good candidate on serialization, and transmission per value, from the server side to the client side.
So we would NOT be in favor of propagating exceptions to the client side.
And just one exception message (i.e. a string) may be not versatile enough.
Sometimes, you need additional structured information.

Of course I need additional structured information. But for now when I'm calling methods of remote service all I have is Message property in EInterfaceFactoryException...

See how ICQRSQuery is defined in mORMotDDD.pas.
I've just updated the documentation, and written a blog article about this point.

Any example of using TDDD* classes would be also very valuable and helpfull.

Last edited by ASiwon (2015-04-12 15:09:11)

ASiwon · 2015-04-12 22:09:58

Maybe I'm wrong (my english is not good) but I think in documentation to the mORMotDDD unit code, for class TDDDRepositoryRestFactory, for method AddFilterOrValidate exists incomplete sentence:

- filters and validators will be applied to the

mORMot Open Source

#1 2015-04-09 10:06:08

How to handle EInterfaceFactoryException properly

#2 2015-04-09 11:26:09

Re: How to handle EInterfaceFactoryException properly

#3 2015-04-12 13:00:12

Re: How to handle EInterfaceFactoryException properly

#4 2015-04-12 13:33:13

Re: How to handle EInterfaceFactoryException properly

#5 2015-04-12 15:07:18

Re: How to handle EInterfaceFactoryException properly

#6 2015-04-12 22:09:58

Re: How to handle EInterfaceFactoryException properly

Board footer