DSRequest error handling: lost errors?

[csillag]

Hi,

Sometimes I dont't get notifications about failed DSRequests.
Here is an example:

I. The client is sending the DSRequest like this:

form.submit(saveReturned, new DSRequest() {{ 
    setOperationId("registerUser");
}});

(Where saveReturned is a DSCallback.)

II. The client sends this request:

{
    "dataSource":"app_users_auto", 
    "operationType":"add", 
    "operationId":"registerUser", 
    "componentId":"isc_DynamicForm_0", 
    "data":{
        "USER_LOGIN":"cs2", 
        "USER_NAME":"Cs 3 ", 
        "USER_EMAIL":"cs3@a.com"
    }, 
    "callback":{
        "target":[DynamicForm ID:isc_DynamicForm_0], 
        "methodName":"saveEditorReply"
    }, 
    "showPrompt":true, 
    "prompt":"Saving form...", 
    "oldValues":{
    }, 
    "clientContext":{
    }, 
    "requestId":"app_users_auto$6272"
}

III. The server executes the operation binding, and (for some reason) the action fails. Server executes this:

return new DSResponse(DSResponse.STATUS_FAILURE);

IV. The client receives this DSResponse:

[
    {
        queueStatus:-1, 
        isDSResponse:true, 
        invalidateCache:false, 
        status:-1, 
        data:null
    }
]

V. The followin appears on dev console log:

14:53:18.266:XRP1:WARN:RPCManager:Error performing operation: 'registerUser': error: FAILURE, response: {operationId: "registerUser",
clientContext: Obj,
context: Obj,
transactionNum: 5,
httpResponseCode: 200,
httpResponseText: "//isc_RPCResponseStart-->[{queueStatus:-..."[123],
xmlHttpRequest: [object XMLHttpRequest],
transport: "xmlHttpRequest",
status: -1,
clientOnly: undef,
httpHeaders: Obj,
isStructured: true,
callbackArgs: null,
results: Obj,
queueStatus: -1,
isDSResponse: true,
invalidateCache: false,
data: null,
startRow: 0,
endRow: 0,
totalRows: 0}

This is all right, but at this point, the specified DSCallback is not called. (Nor is any error message displayed.)

* * *

If I understand this right, I can choose from two error handling modes:
- By default, the central framework will handle errors. This means that in case of errors, RPCManager is supposed to show an error message for me, and my DSCallback is not called. This works fine when there is an error message, but when there is none (like in the example), it just swallows the error.
- The other option is to specify willHandleError="true" on my request. In this case I will get no error message, but my DSCallback will be called in case of errors, too. This option works fine.

So, to wrap this up, the problem here seems to be the RPCManager does not show any error message when there is no message returned with the failed DSResponse. Is that intended?

Thank you for your help:

Csillag

[Isomorphic]

We'll go ahead and add a generic error message for completeness, however, recommended practice is to always include an error message. Otherwise the user is going to see something useless like "Unknown error with code -1".

[csillag]

Originally Posted by Isomorphic

We'll go ahead and add a generic error message for completeness,

Thank you.

however, recommended practice is to always include an error message.

Obviously. Errors with no message are typically generated out of my reach. (For example, there was some time while SmartGWT's built-in SQL backend generated errors like this for failed SQL operations. Fortunately, this is now also fixed.)

Otherwise the user is going to see something useless like "Unknown error with code -1".

True, but someting line "The operation failed." is still much better than total silence.

Thank you for your help:

Csillag

[Isomorphic]

This change has now been made - you should see it in the next nightly build.

[csillag]

Yes, I've tested with the nightly build from 02.23, and it's now working correctly.

Thank you.

Csillag

[csillag]

Originally Posted by Isomorphic

recommended practice is to always include an error message. ".

There is an example when the SmartGWT Serverside still does this, with no error message.

I have an operation binding which contains a CustomSQL tag.

The SQL code is calling a stored procedure.

If the stored procedure does not generate any output, then I get this on the server side:

=== 2011-02-26 23:05:49,575 [0-22] WARN  RequestContext - dsRequest.execute() failed: 
java.lang.NullPointerException
	at com.mysql.jdbc.ResultSetImpl.getRow(ResultSetImpl.java:5291)
	at org.apache.commons.dbcp.DelegatingResultSet.getRow(DelegatingResultSet.java:332)
	at com.isomorphic.sql.SQLTransform.toListOfMapsOrBeans(SQLTransform.java:486)
	at com.isomorphic.sql.SQLTransform.toListOfMapsOrBeans(SQLTransform.java:397)
	at com.isomorphic.sql.SQLDriver.getTransformedResults(SQLDriver.java:310)
	at com.isomorphic.sql.SQLDriver.executeQuery(SQLDriver.java:551)
	at com.isomorphic.sql.SQLDataSource.executeNativeQuery(SQLDataSource.java:376)
	at com.isomorphic.sql.SQLDataSource.executeNativeQuery(SQLDataSource.java:371)
	at com.isomorphic.sql.SQLDataSource.SQLExecute(SQLDataSource.java:1289)
	at com.isomorphic.sql.SQLDataSource.processRequest(SQLDataSource.java:280)
	at com.isomorphic.sql.SQLDataSource.executeCustom(SQLDataSource.java:240)
	at com.isomorphic.datasource.DataSource.execute(DataSource.java:1083)
	at com.isomorphic.application.AppBase.executeDefaultDSOperation(AppBase.java:721)
	at com.isomorphic.application.AppBase.executeAppOperation(AppBase.java:658)
	at com.isomorphic.application.AppBase.execute(AppBase.java:491)
	at com.isomorphic.datasource.DSRequest.execute(DSRequest.java:1465)
	at com.isomorphic.servlet.IDACall.handleDSRequest(IDACall.java:173)
	at com.isomorphic.servlet.IDACall.processRPCTransaction(IDACall.java:130)
	at com.nolmecolindor.sgweet.server.auth.SecureIDACall.processRequest(SecureIDACall.java:27)
	at com.isomorphic.servlet.IDACall.doPost(IDACall.java:54)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
	at com.isomorphic.servlet.BaseServlet.service(BaseServlet.java:152)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
	at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
	at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362)
	at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
	at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
	at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:729)
	at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
	at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
	at org.mortbay.jetty.handler.RequestLogHandler.handle(RequestLogHandler.java:49)
	at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
	at org.mortbay.jetty.Server.handle(Server.java:324)
	at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
	at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:843)
	at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:647)
	at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
	at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
	at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
	at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488)

The client side gets this:

[
    {
        queueStatus:-1, 
        isDSResponse:true, 
        invalidateCache:false, 
        status:-1, 
        data:null
    }
]

I think the guilty party here is the MySQL JDBC connector; there is no reason to throw a NPE when a stored procedure does not generate any output, it's perfectly legal.

However, I think SmartGWT could capture the NPE from JDBC, and return (to the client side) with an error message (something like "Database operation failed").

Thank you:

Csillag

[Isomorphic]

We're returning exception.getMessage() (which appears to be null here).

For now at least, it's up to MySQL to provide better error reporting here. One day we may push our exception handling closer to the source so we can add context where a bug in third-party code doesn't, but this has very little value: the exception is already well-reported in the log and the end user is unlikely to be able to do much with a database error vs general error (and again, this is only due to a MySQL bug - they *would* be able to tell the difference if MySQL reported it properly).

[csillag]

Originally Posted by Isomorphic

[...] the end user is unlikely to be able to do much with a database error vs general error [...]

Yes; but before this fix, errors like this was not reported to the end user in any way - that's why I am showing this example, to prove that this fix is useful :)

Thank you again:

Csillag