Ways to debug Errors & Exceptions in Grails

While working on Grails projects over the time Iv come across some tips and tricks to debug the app quickly. However, Grails provides a long detailed stack trace about exceptions and errors but, sometimes it is difficult to figure out the source of these exceptions. 

It goes without saying that, logging is an important aspect of any application. It allows developers to report textual information about what is going on inside the application. Grails uses it’s common configuration mechanism to provide the settings for logging, using Log4j library. This provides much more configured logging feature by logging type. For more reference read Grails logging here.

Some of the Grails specific debugging practices are enlisted below:

  • For debugging application source code, add logs in the code. Similarly, for plugin code add logs in the cached plugin resource’s code for debugging. In case of a Groovy file, we can simply debug by just looking into the source code in detail.
  • Run your app with the stack trace flag i.e grails run-app stacktrace. Then, check the stack trace and investigate the source code first and eventually check the plugin code for the errors occurred.
  • In case of GSP’s when your stack trace gives information about a line number; open the browser error URL and append “showSource” parameter at the end. This will show you the generated compiled Groovy source code for the corresponding view. You can check the error line number to debug. This only works in development environment. For eg: Browsing to http://localhost:8080/myProject/myController/myAction?showSource will show the compiled Groovy code for “myAction” view and you can look into the problem by jumping on to the line number where the problem occurred.

For generic exceptions in Grails, sometimes it is very difficult to get the source of error. In such cases enabling loggers for some level may help. See the following example:

I upgraded Grails version to 2.4.4 which produced the following exception on run-app:

MappingException: Association references unmapped class: java.util.List

These kinds of generic exceptions do not provide any information about the source. After some investigation, I found a JIRA for it already created in Grails which gave me some pointers regarding the exception. This way, I got an idea about why this exception was thrown at run time. The Exception was thrown by grails-data-binding plugin. At this point, I thought of checking the plugin source code and during that I found some loggers which provided information about the exception.

Exception was thrown from file AbstractGrailsDomainBinder.java. I enabled logs for that particular package with Log4j in Config.groovy as follows and finally I got the cause of runtime exception and fixed it.

log4j = {
    error  'org.codehaus.groovy.grails.orm.hibernate.cfg'
}

Server side exceptions are inevitable but, there are ways to handle them..

Imagine that you wanted to save a record to the Server side database and alas, you saw an internal server  error on your browser.

You went into a dilemma and tried re-filling up the form, refreshing the web page, etc but no help.

On the server-side, it’s likely that there are invalid references which may cause MissingProperty or NullPointer exceptions. In such cases, the Groovy’s Null safe operator (?.) comes to the rescue. Use this operator wherever there are chances of such exceptions.

Now that we have prevented those exceptions, next step would be to throw a humble message to the user explaining the cause of the error and guiding them of the use correct values during the next attempt.

 

Writing huge chunks of code for complex business logic is quite a task, but one should essentially think of the failure cases and handle them at the beginning of the chunk itself.

I have got this advice many a times, “Add a null check at the beginning of a method. It also saves a lot of indentation“. This applies to scenarios where say, I want to submit a user details form to the Server, but I happened to pass an invalid ID (in a hackish way or through some wrong JavaScript code). Hence, there will be an exception at the backend. So, I will guard my code with an initial if block saying:

def getUserDetails(Long id) {
    if (!User.get(id)) {
        respond([success: false, message: “Sorry, no User found!”])
        return
    } 
    // The remaining complex logic here
}

These are some handy-dandy guides for tackling Grails exceptions, and some server-side preventive measures. Would love to know what are yours. Happy debugging 🙂

About CauseCode: We are a technology company specializing in Healthtech related Web and Mobile application development. We collaborate with passionate companies looking to change health and wellness tech for good. If you are a startup, enterprise or generally interested in digital health, we would love to hear from you! Let's connect at bootstrap@causecode.com

Leave a Reply

Your email address will not be published. Required fields are marked *

STAY UPDATED!

Do you want to get articles like these in your inbox?

Email *

Interested groups *
Healthtech
Business
Technical articles

Archives