[Question] how to make runtime exceptions visible in cloudwatch metrics?

[abrabah]

How do i tell aws-serverless-java-container to NOT catch all exceptions, but rather let the lambda fail ?

I need this behavior so that i can observe all unexpected exceptions in cloudwatch metrics (Error count and success rate).. Currently this metric show a success rate of 100% even though the lambda throws un-handled exceptions

I'm using the serverless container together with Jersey.

Edit; tried re-throwing the exception from an ExceptionMapper, but that didn't work either..

[sapessi]

Hi @abrabah, unfortunately this is not possible today. As you said, all exceptions are automatically caught and then handled through the exception mapper. I was going to suggest you re-throw the exception from a custom mapper - weird that it didn't work. Any idea where the exception got stuck?

Anyway, I think this is a perfectly reasonable feature request. We could add a parameter to the ContainerConfig object such as propagateExceptions: boolean or disableExceptionMapper. What do you think? We can definitely get it in for the next release.

You can access the container config singleton from the LambdaContainerHandler object.

[abrabah]

Thanks for the quick reply :)
Re-throwing from inside a javax.ws.rs.core.Response.ExceptionMapperresults in an error message and a stack trace:

SEVERE: An exception was not mapped due to exception mapper failure. The HTTP 500 response will be returned.
<stacktrace ...>

I did manage to propagate exceptions by omit calling JerseyLambdaContainerHandler.getAwsProxyHandler(handler) directly, and rather create an instance of JerseyLambdaContainerHandler with a custom exception handler extending com.amazonaws.serverless.proxy.ExceptionHandler. However, this is probably considered an anti-pattern?

I like your idea of adding a boolean parameter to the ContainerConfig. It would definitely make more sense than extending the ExceptionHandleras I'm currently doing 🙂

[sapessi]

The com.amazonaws.serverless.proxy.ExceptionHandler is there to make it easier to map Java exceptions to HTTP status codes - same as Jersey's exception mapper. However, I wouldn't call creating your own ExceptionHandler to propagate the exceptions an anti-pattern. If that's what you need, you should go for it. Just keep in mind that API Gateway will likely return a 504 (INTEGRATION_FAILURE) to the client in this case.

[abrabah]

Hmm, weird. I'm getting http 502, not 504 from api gateway..

This is how i (in kotlin) initialize the container handler

    JerseyLambdaContainerHandler(AwsProxyRequest::class.java,
       AwsProxyResponse::class.java,
       AwsProxyHttpServletRequestReader(),
       AwsProxyHttpServletResponseWriter(),
       AwsProxySecurityContextWriter(),
       object : ExceptionHandler<AwsProxyResponse> {
          override fun handle(ex: Throwable) = throw ex
         override fun handle(ex: Throwable, stream: OutputStream) = stream.use { throw ex }
       },
       app).also { it.initialize() }

Anyway. I will just keep it like this until the boolean parameter becomes available... Let me know if I can be of any help 🙂

[sapessi]

Sounds good, @abrabah - API Gateway may have changed that to 502.

[sapessi]

Release 1.5 is making its way out to Maven central