You are not logged in.
I was using an old version of mORMot and had 2 methods wich returned a TServiceCustomAnswer (for performance purposes, as they return a lot of data), now I've updated mORMot and the behavior changed for these methods.
When I return a Integer for example in an interface based method service, if something goes wrong on the server, an exception is raised on the client side.
I have a lot of handling for these exceptions, like handling disconnects, proxy errors, expired token, etc.
And now the 2 methodos which returns TServiceCustomAnswer doesn't raise exceptions anymore and I'll have to handle it differently from the other methods.
I agree that raising exceptions isn't REST friendly, but having 2 different behaviours based on the method return is very confusing (took me some time to figure it out) and in my case will result in some duplicated code to handle errors differently in these methods.
Is there some way to maintain the old behavior for theses methods?
Offline
if you have 2 methods in an interface based service, like:
function StringMethod: string;
function CustomMethod: TServiceCustomAnswer;
If you raise an exception on both methods, the behavior on the client is different:
The method StringMethod will raise an exception on the client, and I can handle it like:
try
Response := service.StringMethod;
except
// If something goes wrong in the server, this code will be executed
end
But with a TServerCustomAnswer the exception isn't raised anymore (it was in previous versions) and now I have to handle it like this:
// This method will never raise an exception, even if the connection is down
Response := service.CustomMethod;
if Response.Status <> HTTP_SUCCESS then
// handle the Response
Last edited by fabioxgn (2017-10-18 19:24:55)
Offline
I'm not sure I understand exactly the behavior you are reporting...
Could you be more specific?
Do you need any more info? Thanks.
Offline