RPCManager.setHandleErrorCallback vs RPCRequest response status

[ilab]

Short question: how is it supposed to achieve a centralized error handling for RPCRequests if you are not using Smart GWT Server?

Longer story:

As per the documentation of RPCResponse.getStatus():

When not using the Smart GWT server, the RPCManager makes no assumptions about the structure of the response, so the status code just reflects the httpResponseCode... Default value is 0.

I suppose that is why a supposed-to-be-centralized error handler set by RPCManager.setHandleErrorCallback() will never be called by the framework when Smart GWT server is not used and the server response HTTP status is OK, although the response contains error info in some structured way.

What is the suggested way of making centralized error handling work?

Thank you

[Isomorphic]

You have code somewhere that parses the response and figures out if it's an error. Call that consistently, and that's your centralized error handling. Are we missing something?

[ilab]

By using the term "Centralized error handling" I was trying to refer to "Centralized error handling" which you discuss in your Error Handling Overview .

So, you are missing that you have already introduced a convenient way for centralized error handling (please see your Error Handling Overview), which however does not apply in a special case, when one is using RPCReqest but not using Smart GWT server.

I am trying to suggest that it would make sense to support the way of centralized error handling you introduced even in this case, and not forcing the users of LGPL version to reinvent the wheel and create an own centralized error handling based on your "Custom Error Handling" (please see your Error Handling Overview).

As you have suggested, such a custom-centralized-error-handling could be developed by calling the common error handling code from every single place where RPCRequest is used, instead of specifying the behavior only once, centrally (RPCManager.setHandleErrorCallback()). Or, one could introduce some CustomRPCManager wrapper over RPCManager and use that everywhere instead of calling RPCManager.sendRequest() directly (unfortunately, RPCManager cannot be replaced/customized so this cannot be done without the need of modifying the calling code everywhere).
One could do that, sure. But is it the right way, really?

Thank you

[Isomorphic]

Your forum post here is longer than the code you are valiantly seeking to reuse. RPCManager.handleError() just pops a warn() dialog with the error message. So there's not a lot of reinventing the wheel here.

Second, if you think you will be sending a lot of RPCRequests, you're probably doing something wrong. Typical SmartGWT applications consist of lots and lots of DataSource operations, and just a few basic RPCs. If you create a DataSource class that handles your custom formats, you *do* get to participate in standard error handling. Note that best practice here is to use the protocol offered by RestDataSource, and not reinvent the wheel.

Finally, if your application is one of those very rare one that sends lots of different kinds of RPCRequests, certainly it would be naive to write the parsing and error handling logic inline in every RPC. So just write a method and reuse it.

[ilab]

Your forum post here is longer than the code you are valiantly seeking to reuse. RPCManager.handleError() just pops a warn() dialog with the error message. So there's not a lot of reinventing the wheel here.

Yeah... but... your response doesn't seem to be related to the problem I described. I don't get how the default behavior of RPCManager.handleError() comes here.

Again, what I want to do:

1. Write a general custom (!) error handling routine to handle RPCResponses by parsing the result and do whatever I need (I can do that).
2. Have my custom error handling routine handle all RPCResponses having negative status, without having to call it directly from the callback. I don't want the callback be called at all, if the response status is negative.

Please note that this is exactly how it is actually written and suggested in the documentation in Error handling overview and RPCManager.setHandleErrorCallback.
It just does not work with LGPL version.

Finally, if your application is one of those very rare one that sends lots of different kinds of RPCRequests, certainly it would be naive to write the parsing and error handling logic inline in every RPC. So just write a method and reuse it.

As I wrote, I shouldn't even have to reuse it.
The framework should handle it properly, again, as it is written in the documentation, which unfortunately doesn't work in LGPL version.

[Isomorphic]

We're not sure what part you're now following.. one more attempt to spell it out:

Make yourself a method, call it makeRPCRequestHowIWantTo(). This method calls the framework sendRequest() but passes in a callback that parses the response and does whatever error handling you want, then calls a second callback, which is what your code will pass into makeRPCRequestHowIWantTo(), and that's what you'll use for normal (non-error) handling of the responses.

So then you've got your own centralized error handling that deals with your custom response format, and you're not writing any repeated error handling code. This is just elementary layering of APIs.

[ilab]

Okay, so your suggestion is to layer over the API. (Thank you for describing it in detail, although as I noted above, I was aware of such a layering is possible.)

Just one thing: as this should work out of the box as per the documentation, you could consider to review the "Error handling overview" in https://www.smartclient.com/smartgwt...rHandling.html and point out that the following citation will not work in the case of LGPL Smart GWT:

Centralized Error Handling
If the status field shows a failure, the RPCManager will invoke HandleErrorCallback.handleError(). By default, this logs a warning and shows a dialog with the contents of the response's data field (which is assumed to contain a meaningful description of the error that occurred). If you specified a callback in your request, it will not be called if the status shows a failure (see the section on custom error handling below for how to change this). This default arrangement means that any Smart GWT application has a basic handling mechanism for unrecoverable errors, without any code to write.

You can customize centralized error handling at two levels:

• Use RPCManager.setHandleErrorCallback(com.smartgwt.client.rpc.HandleErrorCallback) to provide your own error handling logic (note that customization takes place at the static class level, not per-instance)

Thank you for your time

[Isomorphic]

As we've covered a couple of times, it would be inaccurate and misleading to say that LGPL does not have centralized error handling facilities, since there is both centralized handling of HTTP errors and of DataSource errors (again see RestDataSource / DataSource.transformResponse). So your suggestion would just damage the docs..

In the massive number of interactions we've had with developers, we've never seen anyone have your particular misunderstanding, so we're going to write it off as idiosyncratic.

[ilab]

LOL, I think that is just because others give up soon because your reading comprehension doesn't seem too strong but then you are often arrogant.

Just take your last message: where did I say that LGPL does not have centralized error handling facilities?
I just made a huge effort to let you know several times and ways that in a special case the centralized error handling does not work as it is described in the docs.

Anyway, I give up too.

[Isomorphic]

Sorry, but, we've understood everything you've been saying all along, it's just that you're not correct.

The last retreat of those who've been proven wrong is to claim no one understands them. We see that a lot, too.