Ultimately, i'd like to
if (badThingsHappen) {
log the issue
throw exception with description
}
The obvious redundancy here is that often exception description and the message to be logged is (often) the same.
This looks needlessly verbose
if (badThingsHappen) {
logger.error("oh no! not again!");
throw new AppException("oh no! not again!");
}
Declaring temporary String feels wrong
if (badThingsHappen) {
String m = "oh no! not again!";
logger.error(m);
throw new AppException(m);
}
Is it ok to have Exception's constructor handle the logging? Is there a better (cleaner) way?
You could use a utility method:
public class AppException extends Exception {
public static AppException logAndThrow(Logger logger, String message) throws AppException {
AppException e = new AppException(message);
// log the stack trace as well
logger.error(message, e);
throw e;
}
}
and the use it:
if (badThingsHappen) {
AppException.logAndThrow(logger, "oh no! not again!");
}
I usually prefer to log exceptions when I catch them, rather then when I throw them.
This cleans up the logs quite a bit more, and also lets the "client" code handle the exception and information output much more precisely, since the information you want to associate with the exception when logging can be dependent of context.
If you do want to log as soon as it happens, I would build the exception and log it before throwing, something like:
if(badthingshappen){
Exception e = new Exception("holy $%##");
logger.log(e);
throw e;
}
A bit verbose yes... but this is java.
Typically when working with Exceptions and logging requirements I include logging support in the Exceptions.
Exceptions typically inherit from a Base Exception class in our project and it has hooks for logging log4j or other logging utilities.
class Problem extends java.lang.Exception {
private boolean debug=false;
public Problem(String message) {
if(debug) {
logging.exception(message);
/* Maybe a stack trace? */
}
}
}
I just wrote an error-logging method myself, today (this is used to log errors if they occur in a listener method, so it's also logging the method in which the error occurred and the object in which the listener is implemented to help tracking):
protected void listenerError(String listenerMethodName, Object listener,
RuntimeException e) {
logger.error("Exception while calling " + listenerMethodName
+ " on object " + listener, e);
throw e;
}
I wrote it in the class in question (or the base class, to be exact), because you probably want to use the logger in that class (and all subclasses). Another option would be to create a utility method in a utility class (I would not write an Exception class for it), and provide the logger as parameter:
class ExceptionUtil {
public static error(Exception e, Logger logger) {
logger.error(e);
throw e;
}
}
You can, of course, provide the method and object as params for this method (or an overloaded version of it), as necessary.
Related
When a sub method throws an exception, would encapsulation in a dedicated "package" exception be considered good pratice ?
public String doStuff() throws UtilsException {
try {
throw new NullPointerException("test");
} catch (NullPointerException e) {
throw new UtilsException("something occured", e);
}
}
//use this exception for all classes of this package / component
public class UtilsException extends Exception {
private static final long serialVersionUID = 1L;
public UtilsException() {
super();
}
public UtilsException(String message, Throwable cause) {
super(message, cause);
}
public UtilsException(String message) {
super(message);
}
public UtilsException(Throwable cause) {
super(cause);
}
}
Could Optional.empty() be an alternative to avoid throwing/catching of a complex app?
public Optional<String> doStuff() throws UtilsException {
try {
return Optional.of("ok");
} catch (NullPointerException e) {
LOG.error("Something append... {}", e.getMessage());
return Optional.empty();
}
}
First, you should never catch a NullPointerException (or runtime exceptions in general) an return someting else like you are doing.
Ok, maybe there are a very few cases where you need to do that (like a buggy third party api).
Exceptions like those (NullPointer, ClassCast, IllegalArgument, ect) happen when your program has a bug and you should let
them bubble up and handle them in some high order component of your program.
That being said, (and there comes the infamous phrase) it depends...
Exceptions are "responsible" for informing errors,thus they need to be informative for the caller will use them to decide what to do. Consider the following:
public void readFile(String path) throws IOException {
// read file content
return content;
}
try {
return readFile("foo.txt");
} catch(FileNotFound e) {
// For this specific scenario not finding the file is not a problem
return "";
} catch(IOException e) {
// This we are not expecting to happen, if the file exists we should be
// able to read it, otherwise we should inform the user.
log.error(e);
display("We had a problem reading the file, Check the file permissions and try again");
}
As you can see in the example above, you won't want to wrap the IOException in another exception in this case
because you will remove the client's ability to decide what to do when an error happened.
Also, note that the IOException is a form of "wrap" since exceptions are objects too you can use inheritance
to generalize what kind of errors your method throws and then throw more specific errors so the caller can
decide what to do.
When to wrap.
There are cases when wrapping exceptions is a good practice and is the way to go.
For example, if you are creating a lib whose main functionality is to get weather information.
For the first version you kept it simple and used a third party api to get the values for the day.
The main method of your api looks like this.
public Weather getWeather(Date day) throws HTTPException {
return weather.get(day);
}
Your api is doing pretty well but you noticed you're doing too much requests to the weather api and
you will have to start paying for it very soon. You then decided to cache the results in a database table
so you can reduce the amount of requests.
public Weather getWeather(Date day) throws HTTPException, SQLException {
Weather w = getFromCache(day);
if (w != null) {
return w;
} else {
return getAndCache(day);
}
}
Now you have a problem, you can't add this new exception to the throws statement because you will most certainly break
your api's users code.
And if you think about it, your api's users are no interested if you had problems getting the data from the wheter api or
from your cache, they just want to be informed of errors. This is a very good case to wrap those exceptions in
a more generic one, like WeatherFetchException.
As you can see, it really depends...
The rule of thumb to me is, keep your exceptions meaningful and if you want to wrap them, do only when
it makes sense and when it doesn't remove the caller's ability to handle errors.
Wrapping exceptions just for the sake of it is most definitely not a good practice.
I tried
public void onFailure(Throwable caught) {
Throwable cause = caught.getCause();
String causeStr = (cause==null) ? "" : ", "+cause.getMessage();
errorLabel.setText(SERVER_ERROR + ": " + caught.getMessage() + causeStr);
But cause is always null and caught.getMessage() always equals the very generic 500 The call failed on the server; see server log for details. I want to throw IllegalArgumentExceptions from the server and be able to show it on the client:
throw new IllegalArgumentException("Email address is invalid.");
Your Exception needs to be Serializable to travel through the cables.
In addition, the best practice says: You should have two exception kinds:
SystemException: that is a fatal exception, the user can't recover (this should not be serializable since you will give the user a feedback of the type "an error occured on the server, please contact the administrator"
BusinessException: which is due to a misuse of your ammplication by the user (ex: UnauthorizedException, BadMailException or more generally InvalidvalueException)
This way you will write System exceptions in the logs and send back business exceptions to the user
You can use com.google.gwt.core.client.GWT.UncaughtExceptionHandler to catch the exception on the server, and then throw your own exception that
implements Serializable, and
is defined in a source folder that is acccessible to (and compiled for) the client.
You could also override the RequestFactoryServlet and pass it a custom exception handler::
public class CustomRequestFactoryServlet extends RequestFactoryServlet {
private static class ApplicationExceptionLogger implements ExceptionHandler {
private final Logger log = LoggerFactory.getLogger(ApplicationExceptionLogger.class);
#Override
public ServerFailure createServerFailure(Throwable throwable) {
log.error("Server Error", throwable);
return new ServerFailure(throwable.getMessage(), throwable.getClass().getName(), throwable.getStackTrace().toString(), true);
}
}
public CustomRequestFactoryServlet() {
super(new ApplicationExceptionLogger());
}
}
In web.xml ::
<servlet>
<servlet-name>requestFactoryServlet</servlet-name>
<servlet-class>com.myvdm.server.CustomRequestFactoryServlet</servlet-class>
</servlet>
I also found you can send back a Google UmbrellaException, but you have to instantiate it a little funny because it only takes Sets in the constructor:
Server
public String getUserId () throws Exception {
Set<Throwable> s = new HashSet<Throwable>(Arrays.asList(new IllegalArgumentException("Hidey hidey ho!")));
if (true) throw new com.google.gwt.event.shared.UmbrellaException(s);
Client
public void onFailure(Throwable caught) {
log.severe("fetchUserName(), Could not fetch username: " + caught.getMessage());
Console
Mon Oct 14 12:05:28 EDT 2013 com.example.client.Login
SEVERE: fetchUserName(), Could not fetch username: Exception caught: Hidey hidey ho!
I liked Zied's and Fred's answers the best as they are the simplest and most transparent. However, no need to use UncaughtExceptionHandler or create SystemExceptions, so it can be even simpler. Just capture exceptions as normal, re-wrap, and throw. No need to litter the server Interface with exceptions (just yours). Any serious errors like OutOfMemoryError will be handled by GWT as normal. Also simpler instantiation than my other answer. GWT already has pass/fail handlers with onSuccess/onFailure so no need to re-check for a failure within onSuccess with a special return value. However, the only way to reach onFailure is with an Exception, so even though a boolean might be sufficient, an Exception is required to indicate an error to the client handler.
MyException
package com.example.shared;
import java.io.Serializable;
public class MyException extends Exception implements Serializable {
private static final long serialVersionUID = 1104312904865934899L;
public MyException() {}
public MyException (String s) {
super(s);
}
}
Server
public void cancelSend() throws MyException {
throw new MyException("Because I said so");
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Log runtime Exceptions in Java using log4j
I am developing a desktop application. I used Log4j to write log. How can I write log with NullPointerException? I didn't predict that could happen.
If you mean just how to print the exception to the log, assuming the configuration is OK:
try {
....something
} catch(RuntimeException e) {
log.error("Got unexpected exception", e);
}
NullPointerException inherits from RuntimeExepction so you can safely catch it and any other runtime ones with the above code.
The above code will NOT catch any exception which is inherit from Exception but not from RuntimeException.
If I understand your question properly, you do not want to put Try catch statements throughout your code to handle NullPointer Exception as it is not expected.
Simple way to handle is to put a null check before using the object reference for any operation. Also , place these null checks only on those objects where you can expect that it might not be initialized due to some other exception or error scenario.
i.e
if (objectReference!=null)
objectReference.CallSomeMethod();
Another example
String listofDefaulters =null;
String defaulters = getDefauter();
/**you might expect that you will always get defaulters from the method call but it might happen dat it can return null value also.
So always put a null check where you are not 100% sure if value will not be null**/
if (defaulters !=null)
defaulters.doSomeOperation();
If you want to do aspect oriented programming, you may want to write an advice around Exception including NullPointerException and perform the logging e.g. below:
#Aspect
public class ExceptionLogging {
private static Logger log = null;
#Pointcut ("call(* *.*(..)))
public void exceptionLogMethods(){
}
#AfterThrowing(pointcut="exceptionLogMethods()", throwing="e")
public void handleException(Throwable ex, JoinPoint jointPoint) {
log = Logger.getLogger(jointPoint.getThis().getClass());
log.debug(jointPoint.getThis().getClass() + ex.getMessage());
}
}
You can use the class Preconditions too in the Guava libraries for customize the exceptions and the messages.
The method Preconditions#checkNotNull(T, java.lang.Object) throws a NullPointerException if the reference T is null.
void method(String name) {
Preconditions.checkNotNull(name, "The name is null.");
// do something with the name
}
void otherMethod() {
try {
method("zerone"); // OK
method(null); // throws NPE
} catch(RuntimeExcetion e) {
LOG.error(e.getMessage(), e); // Message: "The name is null."
}
}
I have a JBOSS ESB that uses a standard out of the box EJBProcessor action. How do I get hold of an exception, if the exception be thrown in the method call that was run in the EJB?
Any advice would be helpful.
You can subclass EJBProcessor and override the process method like this:
#Override
public Message process(Message pMessage) {
try {
pMessage = super.process(pMessage);
} catch (Throwable wEx) {
handleProcessError(pMessage, wEx);
}
return pMessage;
}
You will more than likely catch an instance of ActionProcessingException, and you can look at the cause to see the exception in your EJB.
Your action configuration in your jboss-esb.xml will remain exactly the same, except you will substitute the name of your subclass for org.jboss.soa.esb.actions.EJBProcessor.
Our application uses several back-end services and we maintain wrappers which contain the methods to make the actual service calls. If any exception occurs in any of those methods while invoking a service, we throw a custom exception encapsulating the original exception as shown below.
interface IServiceA {
public void submit(String user, String attributes);
}
public class ServiceAWrapper implements IserviceA {
private ActualService getActualService() {
.....
}
public void submit(String user, String attributes) {
try {
Request request = new Request();
request.setUser(user);
request.setAttributes(attributes);
getActualService().call(request);
} catch(ServiceException1 e) {
throw new MyException(e, reason1);
} catch(ServiceException2 e) {
throw new MyException(e, reason2);
}
}
}
I would like to know if there's any framework that would allow me to
capture (and probably log) all the
parameters passed to my wrapper
methods at run-time; if the methods
are called.
capture the actual exception
object(MyException instance in above
example), if any thrown; so that I
could append the passed parameters
to the object at run-time.
I am currently exploring AspectJ to see if it can address my requirements, but I am not sure if it can be used to capture the parameters passed to methods at runtime and also to capture exception objects, if any occur.
Thanks.
With AspectJ, you can use around advice to execute advice instead of the code at the join point. You can then execute the actual join-point from within the advice by calling proceed. This would allow you to capture the input parameters, log them, and proceed to call the actual method.
Within the same advice you could capture any logs throw from the method, and inspect or log them before passing it back up to higher levels.
Matt B's answer is right. Specifically, you can do something like this:
aspect MonitorServiceCalls {
private final Logger LOG = LoggerFactory.getLog("ServiceCallLog");
Object around() throws MyException: call(public * *(..) throws MyException)
&& target(IServiceA+) {
MethodSignature msig = (MethodSignature)thisJoinPoint;
String fullMethName = msig.getMethod().toString();
try {
Object result = proceed();
LOG.info("Successful call to {} with arguments {}",
fullMethName,
thisJoinPoint.getArgs());
return result;
} catch(MyException e) {
LOG.warn("MyException thrown from {}: {}", msig.getMethod(), e);
throw e;
}
}
}
AspectJ is the right option. You will be able to get hold of the parameters by way of a JoinPoint object that will be passed to your advise methods. You can also get hold of the exception either by implementing an after throwing advise or an around advise.