Question about centralizing RPCRequest server-side error handling

[mathias]

Hello folks! I'm trying to do a bit of refactoring in my smartgwt spring services.

A common use case looks like this:

DSResponse resp = new DSResponse();
try {
    resp.setData(customService.doAddOfTheThing());
} catch (CustomTypeOfException ex) {
    resp.setStatus(Utils.mapExceptionToGlobalResponseCode(ex.getErrorType()));
} catch (Exception e) {
    resp.setStatus(GlobalWebErrorCodeEnum.SYSTEM_ERROR);
}
return resp;

The error code i set in the response is then taken care of in my custom error handling in the client, to present localized user messages and perform context-aware error handling etc.


Now, i would like to centralize this to make the code look cleaner, so i looked a bit at IDACall. From what i can see, in your 'handleDSRequest' method you catch Throwables and then call handleDSRequestError and return what that method returns.


Would it be a "best practice" solution for me to extend IDACall, override the handleDSRequestError and move the code i showed above here (and call super.handleDSRequest if i could not handle the exception)?

Would be great to hear your thoughts.

[Isomorphic]

We're not sure how you're ending up repeating the above code so that it would need to be centralized. Assuming the errors you show at least principally come from DataSources, just put error handling in an override of DataSource.execute() and use the same DataSource subclass everywhere.

[mathias]

I'm pointing to Spring services in my .ds-files and different Datasource definitions call different Spring services. (I use spring services since i want SmartGWT, all my rest/app services, SMS services and other external systems to call the same business logic). So the errors come from my own Service layer, which is called from the IDACall.

[Isomorphic]

Good to know.. this does not seem to conflict with our advice. Use the same DataSource *subclass* in every .ds.xml to inherit the same error handling logic.