Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    Error handling when retrieving a datasource

    I am looking to fine-tune our implementation of the datasource loading to include error information in case the retrieval failed on the server for some reason.

    I am at a point where the
    Code:
    DataSource.getDataSource(dsID)
    returns null in case an error occurred on the server. Currently we throw a general 'Failed to load datasource' error from there to signal the problem.

    This is how we have it at this time:

    Code:
    DataSource ds = DataSource.getDataSource(dsID);
    if (ds == null) {
       throw new MyClientException("Unable to create data source '" + dsID +  "', check application server connection.");
    }
    At best, I would like to include the actual cause of the error (including a text message, error code, trace ...) in the exception which is created there.

    We have an override of the 'DataSourceLoader' servlet in place, where we are able to trap the error and do something with it. I have been looking for some way to send the error information back to the client, but failed to come up with something that does the trick.

    The default implementation of the 'DataSourceLoader' returns the error (when we throw it in our servlet) in HTML format when the debug property is set to true or performs a redirect to the general error page otherwise. The first approach results in a script error on the client. The second approach also gave me a script error on the client but this might have been caused by the lack of a configured error page. I managed to bypass this by also overriding the 'handleError' methods in our custom 'DataSourceLoader' servlet.

    Could you please provide some insight into how this should be implemented or point out what we are missing?


    (We use SmartGWT EE build SC_SNAPSHOT-2011-01-25)
    Last edited by hin3x; 4 Feb 2011, 03:23.

    #2
    We would consider a general client-side error and server-side logging more than adequate for this case (the error does not seem to be user actionable).

    However if you like, you can take advantage of the fact that the DataSourceLoader servlet really just returns JavaScript to be eval()d, write your own version of DataSource.load() that just evals the response and checking whether it's an error (eg look at the response and see if it's one of your HTML documents instead of valid JSON).

    Comment


      #3
      I agree that a 'general' error message is appropriate for most web apps, but our application is oriented towards expert users who want/need to know more when something goes wrong. We also want to do some 'special' handling when certain errors occur.

      I am very intrigued by your suggestion to send JS towards the client though. I fail however to see how it needs to be done.

      We already have a servlet in place which inherits from 'DataSourceLoader' and overrides several methods.
      I overloaded the 'handleError' method where I can send some customized error information towards the client. Based on your implementation I expect that I need something as follows to do the transformation towards JS.
      Code:
      JSTranslater jst = new JSTranslater();
      jst.toJS(errorInfo, response.getWriter());
      The 'errorInfo' instance would be a java object that can be converted to JS.

      My question is, when I take the approach as described here, how can I 'detect' on the client that something went wrong when the code that invokes this servlet is as follows:

      Code:
      DataSource ds = DataSource.getDataSource(dsID);
      if (ds == null) {
         throw new MyClientException("Unable to create data source '" + dsID +  "', check application server connection.");
      }
      The data that is coming back is no longer a 'DataSource' instance, how will your framework handle this? How can I access the error information which I sent back?

      Many thanks for your feedback!

      Comment


        #4
        Again, the response of the DataSourceLoader is JavaScript. So:

        .. write your own version of DataSource.load() that just evals the response and checking whether it's an error (eg look at the response and see if it's one of your HTML documents instead of valid JSON).

        Comment


          #5
          Sorry for that, I was not getting the fact that you were advising me to override some of your JS code.

          I did manage to resolve my issue by leveraging the fact that you 'eval' the JS as returned by the DataSourceLoader though. I now return an expression which directs the code to one of our Java routines to display the error, including all error information as sent back in a JS representation of our exception.

          Thanks for the pointer!

          Comment

          Working...
          X