Topic
  • 6 replies
  • Latest Post - ‏2012-10-15T13:51:02Z by JBird
JBird
JBird
51 Posts

Pinned topic Best Practices for Logging Caught Exceptions

‏2012-10-09T14:19:44Z |
I need to understand what is the best method for logging unexpected errors that I am catching in a portlet in WEF 7. I would envision the error handler would call an action list which would have 2 calls in it. The first would be a method which would contain the appropriate JAVA syntax to make log4j API calls so we may review the application errors aside from server errors/info. The second action would be a static "Problem Occurred..." kind of page. My log4j properties are all default. If the approach above is correct can anyone direct me towards the appropriate code? Otherwise please advise on a different approach.
Updated on 2012-10-15T13:51:02Z at 2012-10-15T13:51:02Z by JBird
  • DGawron
    DGawron
    580 Posts

    Re: Best Practices for Logging Caught Exceptions

    ‏2012-10-09T17:43:56Z  
    It would be better to create a logging LJO rather than an Action List and then call logging methods on the LJO from model actions. In the LJO init you can dynamically create one or more custom Log4J appenders and then log to them. Or you can modify the Log4J config file in WEF, although it may get overwritten if you upgrade or apply a test fix.
  • JBird
    JBird
    51 Posts

    Re: Best Practices for Logging Caught Exceptions

    ‏2012-10-10T13:48:36Z  
    Thanks for your response. I'm still in the dark about the specifics. Could you provide an example of how to do this? Thanks!
  • SystemAdmin
    SystemAdmin
    9029 Posts

    Re: Best Practices for Logging Caught Exceptions

    ‏2012-10-10T14:22:48Z  
    • JBird
    • ‏2012-10-10T13:48:36Z
    Thanks for your response. I'm still in the dark about the specifics. Could you provide an example of how to do this? Thanks!
    Although I don't have the time at the moment to create a sample, I've followed the same approach DGawron mentions in the past.

    In my specific example, we needed a common error handling framework that could be used across all models for dealing with SoapFaultExceptions when using the Web Service Call builders. We created a Java class to handle errors and used the Linked Java Object builder to expose it to the UI model.

    The Java class has methods that can do whatever we want: look up translated error messages from a resource bundle, log messages using LOG4J, set variables in the webapp, redirect to a common error page, etc. The sky's the limit. :-)

    For example, perhaps in addition to an LJO builder that exposes your error handling class, your UI model contains an Error Handler builder. In Error Handler builder, set it's Try action. For the Catch Action, delegate to your custom code exposed by the LJO builder.

    Your custom code might do something like the following:

    public class MyErrorHandler implements Serializable {

    public void handleMyError(WebAppAccess webAppAccess) {

    // Get the exception off of request. For more info, search for bowstreet.errorhandler.Exception in WEF help
    HttpServletRequest request = webAppAccess.getHttpServletRequest();
    Throwable ex = (Throwable) request.getAttribute("bowstreet.errorhandler.Exception");
    String errorMsg = null;

    if (ex instanceof SOAPFaultException) {
    // code to inspect the SoapFaultException
    errorMsg = // use exception info to look up an appropriate message from resource bundle
    } else
    // handle other types of exceptions
    }

    //
    // Maybe log to a Log4J appender here... (Don't even think about writing to SystemOut. Bad!)
    //
    // Set ErrorVariable Variable in model to the error msg from resource bundle
    webAppAccess.getVariables().setString("MyErrorVariable", errorMsg);

    // Go to Error Page in model
    webAppAccess.processPage("MyErrorPage");

    }

    If all your UI models need to do something like this, then perhaps put the MyErrorVariable Variable and MyErrorPage Page in a commmon model, and used the Imported Model builder to import these artifacts into your UI models.

    Sam

    Disclaimer:
    Opinions and ideas my own, and doesn't necessarily reflect IBM's.
  • JBird
    JBird
    51 Posts

    Re: Best Practices for Logging Caught Exceptions

    ‏2012-10-11T14:52:38Z  
    I got this statement to work in a method I built off of yours. If this is not the best practice to log can anyone provid the appropriate log4j code for logging a production application error?

    webAppAccess.logError(errorMessage, ex);

    Thanks,

    Jay
  • SystemAdmin
    SystemAdmin
    9029 Posts

    Re: Best Practices for Logging Caught Exceptions

    ‏2012-10-11T16:13:59Z  
    • JBird
    • ‏2012-10-11T14:52:38Z
    I got this statement to work in a method I built off of yours. If this is not the best practice to log can anyone provid the appropriate log4j code for logging a production application error?

    webAppAccess.logError(errorMessage, ex);

    Thanks,

    Jay
    I recommend reading the Log4J domestication, which provides all the details for creating appenders, how to use the Log4J api to do logging at different levels (warning, error, etc), etc.

    I believe the webAppAccess.logError(..) will log to default Log4J appenders, which are configured in web-inf/config/log4j.properties. You can reconfigure the log4j.properties to suit your needs.

    webAppAccess.logError(..) is a public api, so you're free to use it.

    My opinion is that using Log4J in general (as opposed to doing SystemOuts in the model or in code) is a best practice, but the organization needs to form their own standards on how they want to use Log4J, i.e. do they want to append to a file? Or have log4J send its logs to somewhere else? etc.

    Sam

    Disclaimer: Opinions my own, not necessarily IBM's.
  • JBird
    JBird
    51 Posts

    Re: Best Practices for Logging Caught Exceptions

    ‏2012-10-15T13:51:02Z  
    Thanks for all the help!