I have a generic question regarding to how to design error handling. I want to use some third-party service in my code. Normally I wrap the service within a client class. Then the rest of my code only deals with my client class and is blind to the real service under the hook. My client class has some mechanism to log errors. But it doesn't want to catch and deal any exception from the service. Ideally it should just ignore the exception handling and let the exception propagates to outside. However, if I want to log the exception, I have to do something like this:
try{
.... // call 3rd party service;
}catch(Exception e){ // e is triggered from the service;
Log.error("Oops, an error: " + e); // shall I log the exception??
throw e; // don't swallow the exception;
}
On one hand, I don't want to do this. I can ignore the handling and logging of the exception. Let the caller of my client class handles exceptions or logs errors. The question is, when should I log exceptions and when should I not? I'd like to hear some common practice and principles. Thank you.
Don't log the exception at every level. Log it only at the "top" level. Log it at the point where not logging it would cause the exception to be missed.
That depends on you. My recommendations are to log the exceptions when they indicate something truly unexpected. Granted, the name "exception" would seem to indicate that this is always the case, but not necessarily.
Sometimes, code returns exceptions for scenarios that are unexeceptional.
Sometimes, code calls other code, knowing it will invoke exceptions in certain cases, but the set of exceptions is "OK".
Sometimes, an exception indicates something unexpected really did happen, and that's usually a bad thing. That's when you should log it, or better yet, make sure your code complains loudly.
If there is a fairly low chance of triggering the exception, I see no real reason not to log it. The only reason to not log an exception to help with debugging is if it is continually firing. If you have an exception that has this characteristic, then I suggest you write your code so that you don't have exceptions continually being triggered.
tl;dr: Exceptions are (hopefully) rare, so log them.
Related
Disclaimer : I'm coming from C# world so this is question might be biased by my previous experience
I have a method that is initializing logging. If this fails, the rest of the app should not run as any call to logger will throw a NullPointerException.
Today, my code is catching the exception and printing an error log via System.err. To me, this is a mistake, it should let the exception propagate up until it kills the app.
So I started removing the try catch and I suddenly got complains from the compiler saying that I should declare my exception on the whole stack where this method is called.
I understand the logic behind it and used to found it practical : you know how this method is capable of failing.
However, that doesn't sound right to me in term of separation of responsibility. I don't want the upper layers to be aware of this potential IOException fail, it is a very specialized behavior that shouldn't be known to , for example, the main method.
And, if we push this logic, it means that :
the highest layer will eventually have to declare the whole scope of exceptions (From IO to Network to custom exceptions...)
Any addition of a new exception can potentially impact a lot of files and code
Am I missing something or this is intended exception design ?
I think what you are looking for is not a Java Exception, it is a Java Error.
An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch. Most such errors are abnormal conditions. The ThreadDeath error, though a "normal" condition, is also a subclass of Error because most applications should not try to catch it.
https://docs.oracle.com/javase/7/docs/api/java/lang/Error.html
You can throw a error, which indicates that your app won't work anymore, which you declared as correct behaviour.
You can encapsulate your checked exception in a RuntimeException (or one if its children), which does not force you to declare the exception:
public X execute() {
try {
return someThrowingMethod();
} catch (Exception ex) {
throw new RuntimeException(ex);
}
}
If you can't initialize the logger and this is an enterprise application, I recommend killing your application with an exit code that explains the reason. If this is a client application, I recommend showing a message to the client stating the problem, recommending to the client that you report this back to you, and allowing them the choice of whether to proceed or not
I'm trying to understand difference between error and exception but it looks same thing and on Oracle Official tutorials I read this line.
Checked exceptions are subject to the Catch or Specify Requirement.
All exceptions are checked exceptions, except for those indicated by
Error, RuntimeException, and their subclasses.
Now about I'm thinking it's same. But after searching more I found some difference as theoretical that.
Exception: are recoverable
Errors: not recoverable.
Exception Example:
try{
read file
}
catch(FileNotFoundException e){
// how I can recover here? can i create that file?
// I think we can just make log file to continue or exit.
}
Error Example:
try{
try to locate memory
}
catch(MemoryError e){
// I think we can just make log file to continue or exit.
}
Edited
I'm asking about recover-able and non-recoverable.
Error, as you already figured out, means you are in serious trouble. In a catch block you might be able to do something like logging, but basically that's it.
Non-recoverable exceptions are mostly runtime exceptions like NullPointerException. They are usually the result of some missed checks in the program code. Therefore the solution is normally to fix the code.
A recoverable exception is something that you know beforehand can happen and take certain measures. Think of a web application that calls some backend service. That service may or may not be available which can cause the execution of the operation to fail. Therefore you have a checked exception, in this case most likely a custom exception that you throw, and then handle it in the front end code in a manner where you tell the user, sorry backend service xy is down, try again later or contact support.
Recoverable does not mean that the application can do something to resolve the cause of the exception, though there may be cases where this is possible.
All classes that inherit from class Exception but not directly or indirectly from class RuntimeException are considered to be checked exceptions.Such exceptions are typically caused by conditions that are not under the control of the program.
Example
in file processing, the program can’t open a file if it does not
exist.
Recoverable
So It is very easy to know that if a file does not exists so you dont need to open that file hence that is recoverable
All exception types that are direct or indirect subclasses of RuntimeException (package java.lang) are unchecked exceptions. These are typically caused by defects in program’s code.
Example
ArrayIndexOutOfBoundsExceptions
ArithmeticExceptions
Error
Unrecoverable
So thatswhy program can not recover from these kind of errors or exceptions
Unrecoverable errors are the ones that put the application in an undefined state, like a broken database connection or a closed port, you may handle the error and continue to execute but it would not make sense. Modern languages like Rust and Go use the name panic for errors of these nature, to make the distinction clear. Best action to take is logging the error, if it is possible, and exiting the application.
A recoverable errors are the ones we can handle gracefully, like division by zero or validation errors. It is something expected and the resulting behavior is covered in the language spec. Yes, application behaves erratic when that a recoverable error happens but we can contain it or work around it.
The Object Throwable has 2 childs : Exception and Error.
All Exceptions are recoverable and all Errors are non-recoverable.
All Exceptions are recoverable because you can catch them and let your program continue its execution.
However all Errors , even when you add them to a catch block, will cause the abrupt termination of your program.
Examples of Errors: StackOverflowError, OutOfMemoryError,..
Remark : Checked and unchecked Exceptions are childs of Exception so recoverable.
Is the following way to code good practice?
try {
//my code here
} catch (Exception e) {
logger.error("Some error ", e);
throw new MyCustomException("Some error ", e);
}
Moreover, should I..
use only the logger?
throw only the exception?
do both?
I understand that with throw I can catch the exception in another part of the callstack, but maybe additional logging has some hidden benefits and is useful as well.
Normally, I'd argue that you should either log or rethrow. Doing both will just cause every layer to log the exception again and again, which makes the logs hard to read. Even worse, it's hard to figure out how many errors you actually have - was it seven errors, or seven layers of the app which logged the same error?
This means that if you suppress an exception, you log it and say why you didn't think it was worth rethrowing.
On the other hand, if you re-throw the exception, you know it's either going to be caught and suppressed (in which case the catcher logs the exception and why it was suppressed), or it will bubble up out of your app and be caught by the app container, which will catch and log the exception. Every exception shows up once and only once in the logs.
I use both in some cases, logging and throwing the exception. Especially, it's useful in APIs. By throwing the exception, we allow the caller to handle it, and by logging, we can identify the root cause of it ourselves.
And, if the caller is in the same system, then if we add logs in every catch, there will be duplicate logs.
When using the pattern you suggest, you usually end up with error events being reported multiple times in the log. In addition, it's not always simple to connect between them when reading the log.
Personally I prefer logging error events only once, and doing it in the higher call levels. Therefore I almost never log & re-throw. I usually let the exception go up the call stack until it reached a context where it can be handled somehow, and this is where I log.
If the exceptions are wrapped and re-thrown correctly, the context should be perfectly clear from the stack traces of the single log message.
The proper answer would be: "it depends"
You do want in general log the exceptions that you catch, since they correspond to something going wrong. That is why code analysis tools such as sonar will raise warnings when you do not log them.
Consider the following taks: parsing a file. While parsing the file you actually try to parse each line. Sometimes some lines will be malformed, and therefore you don't want to stop parsing the file because of it. In that case, you probably want to just log the wrong line and keep going on the file.
However, imagine that at some point you encounter an I/O exception while reading (for example some other program deleted the file while yours was accessing it).
In this case, you will probably want to log your log the error you encounter, and throw a new exception to stop processing the whole file.
So in short, you have to think about what is the best thing to do. But both practices are not bad.
I think you may need to use the pattern judiciously. As you've written the above, for each exception you're going to log 2 stacktraces and that may fill your logs with excessive information.
With respect to logging vs. throwing, they're two separate concerns. Throwing an exception will interrupt your execution, prevent any further work, perhaps rollback database commits etc. Logging will simply dump info to the log file (or elsewhere). It's of more use for debugging, and often much more difficult to test.
I know that is really old question, but I have an another solution.
Consider this. You can log the problem in catch block and throw a new unchecked exception (of course with passing the previous one inside). In such solution there is no overflow in the logs and exception still bubble up to the highest level.
try {
//my code here
} catch (SomeException e) {
logger.error("Some error occured", e);
throw new MyUncheckedException("Some error ", e);
}
My opinion.
When you need to throw an exception, no matter if it is a Checked or UnChecked(Most RD would not catch this.). It means that you want to do something else by stopping the process.
When you need to log something.
It means you want to track it.
It's quite different things.
You need to check what you really need.
BTW: If your exception was thrown by getting no data from DB.
I suggest you to modify the process to return an empty Data Object(POJO). It is better than throwing an exception.
I'm trying to better understand exception handling and logging in a j2ee environment to refactor some legacy code (we use log4j for our logging mechanism). Most of our current code does something like the code below on the business tier, however, I'd like to switch over to unchecked exceptions and just ignore them unless it makes sense to handle them somewhere:
try {
doSomething();
} catch (MyException e) {
log.error("Exception:", e);
throw e;
}
After the exception is thrown in the business tier, it is then propagated up to the presentation tier, which again catches the exception and usually wraps it in a PortletException or ServletException and throws it again. Then, it is handled by a Spring handler which shows a 'friendly' message to the user. I'd ultimately like to only handle exceptions for which we want to show a specific error message, and just ignore everything else.
Questions:
Is it necessary to log exceptions in the business tier? If not, do
I need to log exceptions at all (especially unchecked ones)?
What happens to uncaught exceptions that are not logged using log4j?
(If they're still printed in the console, what's the purpose of
log4j?)
I am confused as to how the process works...
Thanks.
EDIT: If an exception occurs in an outside library (Spring, Hibernate, etc), is it assumed that these exceptions will be printed out using whatever logging mechanism is being used? In that case, I guess that I would only need to log the exceptions that my code throws... or am I way off base here?
Before proceeding any further, please take a careful look at:
The following are some of the generally accepted principles of
exception handling:
If you can't handle an exception, don't catch it.
If you catch an exception, don't swallow it.
Catch an exception as close as possible to its source.
Log an exception where you catch it, unless you plan to rethrow it.
Structure your methods according to how fine-grained your exception handling must be.
Use as many typed exceptions as you need, particularly for application exceptions.
Point 1 is obviously in conflict with Point 3. The practical solution is a trade-off >?between how close to the source you catch an exception and how far you let it fall before you've completely lost the intent or content of the original exception.
IBM DeveloperWorks: EJB best practices
It is usually advised that you use checked exceptions for application exceptions at the business tier. I prefer to follow the business interface pattern to decouple the business tier from the user interface and web tier. This will allow me to think of your business tier as a service layer library and callers might want to handle different situations differently when calling this layer. That is one reason you might want to include checked exceptions, since you can react differently to different exceptions. Furthermore, including checked exceptions will usually help the caller code to be better aware of what different situations might arise from invoking some functionality. It could be worth it to take a look at the business delegate pattern and how it might help you with exception handling. In short, the business delegate pattern allows you to create a very thin layer between the business layer and the web layer where you can do things like exception handling.
No matter how you go about doing this, make sure that you understand the implication of adding an application exception to your Java EE application. You may need to investigate how it interacts with your transaction management logic, specifically when it comes to transaction rollbacks. In my line of work, I had to add an #ApplicationException(rollback=false) to forbid the transaction manager from rolling back my transaction when an exception is thrown and propagated upwards.
You may be able to tell I was working with EJB, but the concepts are probably very applicable to your design as well.
So back to your questions:
Is it necessary to log exceptions in the business tier?
It is not necessary if you plan to log it later on. You better devise a logging strategy at a high level and log all caught exceptions there.
If not, do I need to log exceptions at all (especially unchecked
ones)?
I think that you should log exceptions because that will help you debug any issues later on. The user is usually not savvy enough to capture any output that might be produced if the exception propagates and gets printed on his/her screen without you handling it.
What happens to uncaught exceptions that are not logged using log4j?
(If they're still printed in the console, what's the purpose of
log4j?)
I think it will eventually be caught by the web container and be printed out to the console. If an exception propagates upwards and reaches the web container exception handling safety nets, your exception is out of control. It is usually a sign of bad design. It is best if you keep your exceptions under control. Why wonder how a container will react to an uncaught exception? Also how beneficial will that exception be to the user? I think the information presented from uncaught exceptions are almost useless, as they are so far from the source of the error, that they become irrelevant and hard to work with when debugging.
You could create your own exception hierarchy to wrap them to quickly identify from where in your application architecture it is originating. Also one can go a step further to provide codes and reasons that covers majoority of the use cases.
What logging helps you is to identify the sequence of events, when potentially multiple clients are slamming the same use case or hitting a bottle neck. The logging give you a sequence to trace back because requests increasesed there was congestion in this query causing it to timeout and thus other users where seeing another exception.
While handling the application and showing it to the user is another issue.
Cheers!
We definitely do not have to handle exceptions just to log them. I believe we should catch exception if we then throw other exception that contains the source exception as its cause or if we implement some logic that must be implemented in current layer when exception is thrown.
Yes, it is a little bit verbose to declare all methods as throws MyException. This is the reason that Spring (that you use) prefer working with unchecked exceptions. BTW this is the new feature in Java 7: you can ignore exceptions without declaring that method throws it.
I believe that we still need checked exceptions for development of libraries that expose API to 3rd party applications. Application layer exceptions should be mostly runtime and be caught in one central place.
Is it necessary to log exceptions in the business tier?
No. But more logs = better understanding what is going on. In other way more logs = lower performance.
What happens to uncaught exceptions that are not logged using log4j?
You lost them. Logger pretty things that you can save logs in the place where you need and use filters to get only actual logs for now.
You don't need to catch the business exception (as long as it's unchecked). You don't need to handle them or to log them. You can just swallow them. The problem is - what is such exception for?
Exception signals some inappropriate behaviour in the workflow of your application. If it's checked you, typically, can do something about it - try do some operation again, do some workaround, try different action, etc.
If it's unchecked, it is typically an exception you don't know how or can't handle.
It's considered a code smell if all you do is catch an exception and log it. It's not as bad as swallowing it, but still - it's not good.
Some of the containers (i.e. EJB) is required to log occurred exceptions. Moreover, in EJB 3.x if you're in a JTA managed transaction, and you won't catch an unchecked exception which is not marked as #ApplicationException(rollback=false) than the transaction will be automatically rolled back. This might be the reason why you can see some try...catch blocks with just logging code inside.
If you want to get rid of exception handling code in your business logic, you might introduce an interceptor which will react appropriately upon particular exceptions.
HTH!
Firstly, you can and must log the exception stack trace of all exceptions. In fact, IMO if you only log that an exception happened you might as well not log it at all. However, very often what this leads to is a relaxed view of exceptions. What you should strive for is to have 2 log files or one specific category that if exceptions are in that category they mean something critical happened and must be addressed. Even if that means logging the same exception many times. Rather too many than not at all.
Secondly, it's fine to change all exceptions to checked exceptions - the majority of exceptions are not "recoverable". What I have done that worked well is simply wrap all transactions in an exception handling wrapper which logged the exception, then I can guarantee that all exceptions are logged. Furthermore, create a bunch of exception classes that extend runtime exception - this is much better than rethrowing exceptions as runtime exceptions as very often the inner exception stack trace is not logged in full when you wrap exceptions.
And thirdly, it is important to create a mechanism to map exceptions that do filter through to the front end with the back end cause. This is challenging but it's quite important. Errors that the user sees are far easy to track down if you can map them back to an exception stack trace in the log file.
I created a CustomExceptionClass that its messages are from a configuration file and are a friendlier message to the user.
Then I want to log wich exception was thrown because, if something went wrong, I want to know details then I can fix this. So, I have a doubt.
Where to log these exceptions using log4j? Inside the CustomExceptionClass, or I let the method that throws this exception log it?
You should log wherever you are catching the Exception. If you are not catching it anywhere it really depends how you are running your application.
I'm not sure if you have a question about log4j in particular, but that API simply requires something to call log.error(Object,Throwable), passing in the message as the first parameter and the error as the second parameter. (log is of course a Log4J logger reference.)
Regarding the question of where to call log.error, do not call log.error from within your CustomExceptionClass subclass of Throwable. Instead, I'd make the decision as follows:
If you want to log details about exactly what happened, but you don't plan to put those details into your subclass of Exception, then log the details before throwing the error.
Similarly, if you want to log something specific regardless of whether or how the Exception is caught, then obviously you need to do this before throwing the Exception. You have relatively little control over who calls a non-private method.
Otherwise log in the catch block. This allows you to track both what happened and how your application responded as a result. If you just have the first piece of information, then other people will have to read the code in order to understand "so what?"
Finally, it's considered to be good practice to use uncaught exception handlers for all threads. See Thread.UncaughtExceptionHandler for more details. Basically you really want to at least log all Exceptions in long-running applications.
You should log it in the error handling code, not where the error is initially created.
I typically overload ToString and/or GetMessage in custom exceptions and simply log them per normal.