Problem / Best practice with HTTP 0 error RPCManager setHandleErrorCallback

[Blama]

Hi Isomorphic,

I'm using current SmartGWT 5.1 and would like to exchange the default error message for "http 0".
I have users with a weak connection and they keep thinking my application is down and notice that it is actually their connection only when they try to open google etc.

I'd like to replace the very technical error message



I read the error handling docs and the RPCManager docs.

Using setHandleTransportErrorCallback() with SC.warn(myMessage) as only action does not solve the problem.
The code is executed (breakpoint is hit), but the same message is displayed. I think this is because this:

The default implementation takes no action - by default transport errors are handled via handleError(), or by the standard request callback methods, depending on request.willHandleError. To perform custom handing for transport errors this classMethod may be overridden as follows

The handleError() is called as well and does it's SC.say(). Displaying two SC.say() usually does not work, so I think this is what is happening.

What I would like to do is a

if (httpCode = 0)
  SC.say(myMessage);
else
  super();

but there is no such super().

I also tried to find the default handleError-implementation which does

By default handleError() always logs a warning. In addition, if response.data was set to a String, a warning dialog will be shown to the user with response.data as the message, which allows the server to send user error messages back without writing custom client-side error handling.

in the modules-debug, but did not succeed.

What is your suggestion to solve this case?

Thank you & Best regards
Blama

[Isomorphic]

We've added a new API, RPCManager.cancelDefaultErrorHandling(), which can be called from inside a HandleTransportErrorCallback to prevent the default handleError() method from being called for the DSResponses associated with the transaction that triggered the callback. The change has been applied to SGWT 5.1p/SC 10.1p and newer, and will be in the nightly builds dated 2016-03-26 and newer.

[Blama]

Hi Isomorphic,

thanks for adding.
I'll try this and let you know.

Best regards
Blama

[Blama]

Hi Isomorphic,

using this in v10.1p_2016-03-27 seems to solve the use case:

RPCManager.setHandleTransportErrorCallback(new HandleTransportErrorCallback() {
    @Override
    public void handleTransportError(int transactionNum, int status, int httpResponseCode, String httpResponseText) {
        SC.warn("Is your internet connection working?");
        RPCManager.cancelDefaultErrorHandling();
    }
});

Thank you,
Blama

[Blama]

Hi Isomorphic,

this seems only to be working when the request is directly made by user code (e.g. DataSource.fetch(), DataSource.performCustomOperation()) and not if the request is issued by a ListGrid or DynamicForm (using v10.1p_2016-04-05).
Could you change this?

Best regards
Blama

[Isomorphic]

To clarify, are you saying that for a ListGrid or DynamicForm, the HandleTransportErrorCallback runs but the RPCManager.cancelDefaultErrorHandling() isn't working to stop the default handling? Do you see this with a simple fetchData() for a ListGrid or DynamicForm, or is some more specific series of events required to see it?

[Blama]

Hi Isomorphic,

exactly. Putting a breakpoint in the HandleTransportErrorCallback shows that it is hit, but the behavior is as if the HandleTransportErrorCallback with its SC.warn() and cancelDefaultErrorHandling() was not there.
In my application this is triggered a simple ListGrid.fetch(), nothing "fancy" (no queue, no callback).

Best regards
Blama

[Isomorphic]

We've applied a fix for this to SGWT 5.1p/SC 10.1p and newer. It should be in the nightly builds dated 2016-04-13 and beyond.

[Blama]

Hi Isomorphic,

thank you, this is working using v10.1p_2016-04-18.

Best regards
Blama