dancablam
19 May 2009, 11:18 AM
I think there's something awry with the description of exception handling in the Ext.Direct remoting specification (http://extjs.com/products/extjs/direct.php):
If an exception occurs on the server-side the router should also return the following error information when the router is in debugging mode.
* type – 'exception'
* message – Message which helps the developer identify what error occurred on the server-side
* where – Message which tells the developer where the error occurred on the server-side.
This exception handling within the router should have the ability to be turned on or off. This exception information should never be sent back to the client in a production environment because of security concerns.
Exceptions are meant for server-side exceptions. Not application level errors.
According to that, in a production environment the router should NOT return 'type'='exception', 'message', or 'where' information. If that's the case, then there's no way (in a production environment) to detect any kind of exception from the server on the client-side.
I believe the spec needs to clarify that the type=exception (and possibly the message) should be included but that the 'where' data (ie the stack trace) should be omitted.
Thanks,
Dan
Addendum
For those needing to send errors to the client (ex: form validation, authentication, and other non-system errors) I use the following result data layout.
{
"type":"rpc",
"tid":2,
"action":"myAction",
"method":"myMethod",
"result":{
"success":true,
"message":"Operation successful",
"data":[
]
}
}
There's no one-right way to do this, but this is what I use to determine if the operation was successful (success:true/false), get any relevant messages from the server, and get any data from the server.
Hope this helps someone.
Cheers,
Dan
If an exception occurs on the server-side the router should also return the following error information when the router is in debugging mode.
* type – 'exception'
* message – Message which helps the developer identify what error occurred on the server-side
* where – Message which tells the developer where the error occurred on the server-side.
This exception handling within the router should have the ability to be turned on or off. This exception information should never be sent back to the client in a production environment because of security concerns.
Exceptions are meant for server-side exceptions. Not application level errors.
According to that, in a production environment the router should NOT return 'type'='exception', 'message', or 'where' information. If that's the case, then there's no way (in a production environment) to detect any kind of exception from the server on the client-side.
I believe the spec needs to clarify that the type=exception (and possibly the message) should be included but that the 'where' data (ie the stack trace) should be omitted.
Thanks,
Dan
Addendum
For those needing to send errors to the client (ex: form validation, authentication, and other non-system errors) I use the following result data layout.
{
"type":"rpc",
"tid":2,
"action":"myAction",
"method":"myMethod",
"result":{
"success":true,
"message":"Operation successful",
"data":[
]
}
}
There's no one-right way to do this, but this is what I use to determine if the operation was successful (success:true/false), get any relevant messages from the server, and get any data from the server.
Hope this helps someone.
Cheers,
Dan