DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

How does AI transform chaos engineering from an experiment into a critical capability? Learn how to effectively operationalize the chaos.

Data quality isn't just a technical issue: It impacts an organization's compliance, operational efficiency, and customer satisfaction.

Are you a front-end or full-stack developer frustrated by front-end distractions? Learn to move forward with tooling and clear boundaries.

Developer Experience: Demand to support engineering teams has risen, and there is a shift from traditional DevOps to workflow improvements.

Related

  • Consumer-Driven Contract Testing With Spring Cloud Contract
  • How Spring and Hibernate Simplify Web and Database Management
  • Functional Endpoints: Alternative to Controllers in WebFlux
  • Graceful Shutdown: Spring Framework vs Golang Web Services

Trending

  • KubeVirt: Can VM Management With Kubernetes Work?
  • Mastering Kubernetes Observability: Boost Performance, Security, and Stability With Tracestore, OPA, Flagger, and Custom Metrics
  • Evaluating Similariy Digests: A Study of TLSH, ssdeep, and sdhash Against Common File Modifications
  • Safeguarding Cloud Databases: Best Practices and Risks Engineers Must Avoid
  1. DZone
  2. Coding
  3. Frameworks
  4. Don't be Careless With Groovy (Un)checked Exceptions

Don't be Careless With Groovy (Un)checked Exceptions

By 
Marcin Pilaczynski user avatar
Marcin Pilaczynski
·
Feb. 19, 16 · Analysis
Likes (10)
Comment
Save
Tweet
Share
19.8K Views

Join the DZone community and get the full member experience.

Join For Free

Groovy language introduced many interesting features from Java programmer's point of view. One of them is the lack of differentiation between checked and unchecked exceptions - a nice quality for programmers who struggled with checked exceptions requirements. It turns out, however, that using this neat Groovy feature with existing frameworks can sometimes be tricky which I've experienced lately.

I worked with relatively straightforward microservice written in Groovy. It was built on top of Spring Boot 1.3. Among others, it used @RestController to define REST endpoints and @ControllerAdvice to handle exceptions thrown by the controller or its internals.
Very simplified example code looks like this (complete source code can be downloaded from https://github.com/yu55/groovy-undeclared-throwable-demo ):

import org.springframework.web.bind.annotation.RequestMapping
import org.springframework.web.bind.annotation.RestController

@RestController
class ExampleRestController {

    @RequestMapping(value = '/get')
    String get() {
        /*
         Lets imagine this exception is thrown somewhere from deepest layers of our service code
         and we don't have to be immediately aware of this.
          */
        throw new ExampleRestControllerException()
    }
}

Controller advice:

import org.springframework.web.bind.annotation.ControllerAdvice
import org.springframework.web.bind.annotation.ExceptionHandler
import org.springframework.web.bind.annotation.ResponseBody

@ControllerAdvice
class ExampleRestControllerAdvice {

    @ExceptionHandler(value = ExampleRestControllerException.class)
    @ResponseBody
    String onExampleRestControllerException() {
        return 'ExampleRestControllerException handled in ControllerAdvice'
    }

    @ExceptionHandler(value = Exception.class)
    @ResponseBody
    String onException() {
        return 'Exception handled in ControllerAdvice'
    }
}

Simple checked exception:

class ExampleRestControllerException extends Exception {
}

When ExampleRestControllerException was thrown, it was handled by onExampleRestControllerException() method in ExampleRestControllerAdvice class.

And this worked perfectly fine.

But I had to add a simple aspect after the returning of get() method in ExampleRestController to do some additional stuff.

@Aspect
@Component
class RestControllerAspect {

    @AfterReturning('execution(* org.yu55.ued.controller.ExampleRestController.get())')
    public void logServiceAccess(JoinPoint joinPoint) {
        // empty implementation for clarity reasons
    }

With this simple aspect introduced, the microservice began to behave strangely. ExampleRestControllerAdvice started calling the onException() method instead of onExampleRestControllerException() when ExampleRestControllerException was thrown. I didn't expect that. What happened?

When the aspect for ExampleRestController.get() method is defined, the Spring generates a proxy for ExampleRestController. Since ExampleRestController doesn't implement any interface, Spring uses CGLIB library instead of java.lang.reflect.Proxy for a dynamic proxy generation [1]. Generated proxy class name is similar to ExampleRestController$$EnhancerBySpringCGLIB$$8d751c8@4481 and it's an ExampleRestController subclass which intercepts all methods calls. There is also another dynamically generated class created:

ExampleRestController$$FastClassBySpringCGLIB$$b01891ea which is a ExampleRestController class wrapper. This wrapper class promises faster methods invocations than the Java reflection API [2].

Spring is invoking get() method (via sun.reflect reflection classes) on enhancer class which then invokes get() method (via CGLIB MethodProxy) on fast class instance. When controllers get() method throws ExampleRestControllerException it's rethrown by fast class to an enhancer class and then the enhancer class get() method throwsjava.lang.reflect.UndeclaredThrowableException (which contains ExampleRestControllerException inside).

This results in ExampleRestControllerAdvice matchingUndeclaredThrowableException with Exception class and firing handler method different than expected.

Sequence diagram

But why UndeclaredThrowableException is thrown? Because the get() method written in Groovy in fact didn't declare any checked exceptions that it could potentially throw. The proxy doesn't know anything about that controller is written in Groovy and no throws declared means that checked exception may still occur. This behaviour also corresponds to Proxy documentation [3].
The issue can be fixed easily by adding checked exceptions to get() method definition or defining ExampleRestControllerException as runtime exception. Former solution technically works but isn't 'groovy' though and the latter is an approach that Spring prefers and is currently considered to be best practice for exception handling [4].

At the end, I would not blame Groovy for this situation. Instead, I would rather point that despite the fact that Groovy simply don't care about checked exceptions, it doesn't mean that other libraries also don't care. This is not what most programmers think of first when using Groovy. A similar situation may happen with any other JVM language that 'ignores' checked exceptions.

The best thing we can do to protect ourselves from situations like this is to prepare tests carefully. Imagine no controller tests for ExampleRestControllerException case - whole application builds and runs perfectly on production until this special case occurs and controller simply returns a wrong answer to the client. A bug like this may not be so obvious and fast to track or fix.

Groovy (programming language) Spring Framework

Opinions expressed by DZone contributors are their own.

Related

  • Consumer-Driven Contract Testing With Spring Cloud Contract
  • How Spring and Hibernate Simplify Web and Database Management
  • Functional Endpoints: Alternative to Controllers in WebFlux
  • Graceful Shutdown: Spring Framework vs Golang Web Services

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • [email protected]

Let's be friends: