I have just implemented exception handling for a unique-constraint of a JPA entity. It is working as I want it to, but when triggered dumps the handled exceptions to the container logfile.
A JPA entity is managed by a SLSB (Service Façade). The Service Façade is called from another SLSB, which provides remoting capabilities based on JAX-RS.
In the Service Façade, the EntityManager operations are wrapped in a try-catch-block, detecting the cause of the unique-constraint-violation. It then throws a custom checked ApplicationException.
The REST-Bean catches the ApplicationException and throws a custom unchecked BadRequestException.
An ExceptionMapper outputs the BadRequestException to the remote client.
This is all working well. The part that I don't understand is: the (handled) exceptions get logged in the container's logfile (complete with a long stacktrace):
[#|2010-09-29T18:49:39.185+0200|WARNING|glassfish3.0.1|org.eclipse.persistence.session.file:/Users/hank/NetBeansProjects/CoreServer/build/classes/_coreServerPersistenceUnit|_ThreadID=30;_ThreadName=Thread-1;|
Local Exception Stack:
Exception [EclipseLink-4002] (Eclipse Persistence Services - 2.0.1.v20100213-r6600): org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Duplicate entry....
....
Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Duplicate entry....
and from throwing the BadRequestException:
[#|2010-09-29T18:49:39.336+0200|WARNING|glassfish3.0.1|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=30;_ThreadName=Thread-1;|A system exception occurred during an invocation on EJB ShopperResource method public javax.ws.rs.core.Response mvs.gateway.ShopperResource.create(javax.xml.bind.JAXBElement)
javax.ejb.EJBException
at com.sun.ejb.containers.BaseContainer.processSystemException(BaseContainer.java:5119)
....
Caused by: mvs.api.exception.BadRequestException: mvs.api.exception.MvsCause: Field 'MSISDN' must be unique!
Is this how it should be? I thought since I handle the exceptions, they wouldn't be dumped to the log?
The exceptions are logged because you have exception logging enabled.
Exceptions get logged by default when your log level is WARNING or greater. If you set your log level to SEVERE or OFF then they will not be logged.
i.e.
"eclipselink.logging.level"="SEVERE"
You can also set the "eclipselink.logging.exceptions"="false" property to disable just exception logging.
See,
http://wiki.eclipse.org/EclipseLink/Examples/JPA/Logging
It's the database layer that does the logging of the exceptions. The time you catch them they are already written to the log.
Related
I've a question regarding capture of "uncaught" exceptions, which appears with stack trace on System.err, circumventing logging configuration: All the other log messages appear properly formatted on System.out (JSON-formatted in my case). But this doesn't happen with Exceptions and stack traces "logged" to System.err!
I've recognized this to happen under at least two circumstances:
Asynchronous execution of tasks (HTTP requests in my case) via ExecutorService (as mentioned in "Scheduled Tasks" chapter). I've added #Retryable annotation to the method; but after all retries fail, "final" Exception thrown by last unsuccessful retry appears on System.err with its stack trace (the other ones thrown by earlier failed retries do not appear, seems they are caught by retry "mechanism" under the hood).
With Exceptions thrown by failed Health indicators (they are implemented by subclassing AbstractHealthIndicator).
I've tried implementing my own TaskExceptionHandler, replacing the default one (also mentioned in "Scheduled Tasks" chapter); and/or by adding System.setErr(System.out) in main method before building/setup of Micronaut Application Context. But nothing seems to help as my test cases attest.
Have I missed a chapter in Micronaut's documentation?
Thanks for any hints.
Regards
Christian
My wager is that Micronaut doesn't provide tools for setting a global uncaught exception handler because that's governed by the wider JRE. We've solved the problem in a few of our services with Thread.html#setDefaultUncaughtExceptionHandler by doing something like this at application startup:
Thread.setDefaultUncaughtExceptionHandler((t, e) -> logger.error("Uncaught exception", e));
In .NET Core you can easily add a detailed exception page for developers:
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
}
This then gives you the exception details:
However, I'd like to include additional exception detail - for instance the SQL query attempted when the exception is a SqlException.
I can write my own exception handler from scratch with app.UseExceptionHandler, but I'd rather extend the built-in error. For instance by adding a tab to the results including additional info.
Is it possible to extend the information on this exception page?
What does 'segment' and 'progress' mean in that kind of exception
2) xlang/s engine event log entry: Uncaught exception (see the 'inner exception' below) has suspended an instance of service 'MainEventProcess.MainEvent(5b530a24-7336-4695-78ee-1d4ffdd9f210)'.
The service instance will remain suspended until administratively resumed or terminated.
If resumed the instance will continue from its last persisted state and may re-throw the same unexpected exception.
InstanceId: cf584087-a9d3-4be7-8da7-eae49fd4a108
Shape name: SendDeviationOut
ShapeId: dc5c3484-7955-4d75-b1f9-7e0ca8ecbc1e
Exception thrown from: segment 4, progress 8
Inner exception: Exception occurred when persisting state to the database.
Full details hereon MSDN:
Exception during execution of Orchestration
Can it be helpful in searching errors in code?
First, it's nothing you need to worry about and is not related to your app/code/implementation.
The two items you need to act on are SendDeviationOut and Exception occurred when persisting state to the database. You are most likely publishing a message and there are no Subscribers. This is the "no Subscribers found" error from the Orchestration engine.
Now, to answer your specific question, those are markers to blocks of C# code that XLang compiler generated from your Orchestration. Basically, every statement is organized into a group, segment, and each is executed and tracked individually, progress. If you open the File0.cs, you will see this in action.
What is the concept behind exception handling in Spring Integration or any other EAI framework: Are they treated as a Message?
Lets say that a JMS timeout exception was thrown from jms-outbound-gateway. Now it has to be moved all the way upto the parent custom gateway addEmployeeGateway which defines a method called addEmployee which throws a custom exception called SystemDownException. These two components are connected through request and reply channels and thats the only medium of communication. Does it mean that Exceptions are also treated as messages?
Also, if i had to map the JMS timeout exception to my custom exception SystemDownException and rethrow the SystemDownException how and where would i achieve this. I dont want to use an errorchannel.
The general mechanism for handling exceptions is an error-channel on the inbound (or some intermediate) endpoint; the ErrorMessage payload has failedMessage and cause properties.
The mechanism is similar to try {...} catch {...} in Java.
I dont want to use an errorchannel.
Alternatively, you can configure a custom request handler advice on the JMS outbound gateway; there, you can do whatever you want, including throwing your SystemDownException after catching an exception on callback.execute().
Does throwing an exception in a windows service crash the service?
i.e. it will have to be restarted manually
Note:
I am throwing the exception from within the catch clause.
Not strictly so -- it'd only cause problems if the exception is unhandled.
If the exception is uncaught and bubbles back up to the OnStart() method it will crash the service. You will typically see a message in the Windows Event Log similar to the following:
"The MyServiceName Service service terminated unexpectedly. It has done this x time(s).
If you're throwing the exception in Catch, and there's nothing above it to recatch it, then that will cause your service to stop. The OnStart() method needs a try/catch. If you don't want to stop the service when an Exception occurs, then you need to handle it (log it and move on, or whatever).
My preference woudld be to handle expected exceptions, and to have unexpected exceptions either cause the service to stop, or at least stop/restart automatically. If something unexpected happens your service will be running in an unknown state, and who knows what it will do.
We ran into the problem of an untrapped exception on a child thread causing the service to stop without providing any information about what was causing the exception. We used this method to find out the source of the exception.
You can put a Handler to the service to catch all unhandled exceptions (including all sub threads of the service). In VB.NET, you will need to add a handler for AppDomain.CurrentDomain.UnhandledException. It is likely similar in C#. It will then catch anything that does bubble up past your onStart. You can choose to consume it there or allow it to crash the service from there.