I have a Java Class which does JNDI lookup and returns lookup ejb object. And if there is failure in lookup various exceptions are handled, when there is failure it will return null.
Now when that API is called and lookup fails we will get nullpointer exception. We can do a null check in calling class but I need exact reason for failure .. How to catch those exceptions thrown in base class?
Don't catch exceptions or if you need to catch them to do some specific work, rethrow them when done so the caller can see there was an exception and handle it itself too.
Like:
method1() {
try {
// SomeException is thrown here
} catch (SomeException e) {
// do some work because of the exception
throw e // re-throw or throw new MyException(e)
}
}
method2() {
try {
method1();
} catch (SomeException e) {
// something went bad!
// do some specific work?
}
}
If you want to transfer error information upwards in the call chain, the best way to do that is with an exception.
Instead of returning null on a failed look-up you should either let the look-up exception propagate up or wrap it in a custom exception if you want to add additional information.
Related
public void backendExecute(Map appParams, BackendTaskMetaData metaData) throws Throwable {
try {
PeriodicTaskData ptd = (PeriodicTaskData) appParams.get(PeriodicTaskData.PARAM_KEY);
String bizKey = ptd.getBusinessKey();
} catch (Exception e) {
LogServices.app.error("RPTPeriodicReportGenTask:"+ e.getMessage());
}
}
With regards to the method above, if object pointed to is null, would come across as NullPointerException, I want to know if this exception would be caught or thrown to the invoker method? thanks
Exception is a parent class of NullPointerException, so it will catch it and not throw it to the calling method.
As you are catching Exception class and NullPointerException is its subclass , exception will get catched not throwed.
Regard to above method, if object ptd is null, would come across nullpointexception,
Yes.
i want to know this exception would be catch or throw it to invoker method?
The exception would be caught by the handler. The handler will catch Exception and any exception that is descended from it. NullPointerException is a subclass of RuntimeException which is (in turn) a subclass of Exception. Therefore, it will be caught.
Now, if this may be just an illustrative example ... but it is a bad idea to:
declare a method as throws Throwable, or
catch Exception ... unless you are about to terminate the application.
Declaring a method as throwing Throwable makes it next to impossible for the caller to know what exceptions could be thrown. Instead, the compiler will insist that the caller catches ... or propagates Throwable.
Catching Exception has the problem that you will catch every subtype of Exception ... including various unchecked exceptions that 1) you are not expecting, and 2) are probably symptoms of bugs that you cannot safely recover from.
NullPointerException is a subclass of Exception and thus will be catched, however it is recommended that you don't try and catch runtime exceptions. It is better to avoid them.
For example a null pointer could be avoided by doing the following:
if(ptd != null) {
ptd.getBusinessKey();
} else {
//Notify the user in some way or do something else.
}
catch (Exception e)
means that this will catch any exception (i.e. any subclass of Exception) thrown inside the preceding try block - which, yes, includes NullPointerException. Note that this is generally considered a bad practice, as you almost always will want to handle different sorts of exceptions in different ways, hence the need for multiple catch statements.
For instance, consider a method that could potentially throw an IllegalAccessException at compile time or a NullPointerException at runtime - it's difficult to imagine a situation where you'd want to handle them the same way, so you'll typically want to do something like this:
try {
PeriodicTaskData ptd = (PeriodicTaskData) appParams.get(PeriodicTaskData.PARAM_KEY);
String bizKey = ptd.getBusinessKey();
} catch (NullPointerException e) {
//do something
} catch (IllegalAccessException e) { //for example...
//do something different
}
Setup
So I have two exceptions:
ProfileException extends Exception
UserException extends Exception
One of my helper class method throws these two exceptions togeather:
Long getSomething() throes ProfileException, UserException
I invoke this method inside a try catch block like this.
try
{
Long result = helperObj.getSomething();
}
catch(ProfileException pEx)
{
//Handle profile exception
}
catch(UserException uEx)
{
//Handle user exception
}
Question
Now I NEED to necessarily distinguish between those two exceptions thrown by the method and handle the exceptions separately depending on the type of exception being thrown.
However I get the following error.
Unreachable catch block for UserException. It is already handled by the catch block for ProfileException.
How can I distinguish and handle seperately depending on the type of exception thrown by that getSomething() method?
This error indicates that UserException extends ProfileException
Since both exceptions are in the same level in the heirarchy, you have to use like following
try {
Long result = helperObj.getSomething();
}
catch(Exception ex) {
if (ex instanceOf ProfileException) {
//Handle profile exception
} else if (ex instanceOf UserException) {
// Handle user exception
}
}
I'm quite convinced that UserException probably extends ProfileException. If you modified it, it's probable that the IDE did not compiled the latest version (for instance because compiler errors occured). Therefore you can run a clean and build command (available in most popular IDEs).
You can simply resolve the problem by swapping the catch blocks:
try {
Long result = helperObj.getSomething();
} catch(UserException uEx) {
//Handle user exception
} catch(ProfileException pEx) {
//Handle profile exception
}
Most IDE's however will always write catch blocks from specific types toward more general types in order to prevent such dead code.
I'm extending the class RecordingCommand from org.eclipse.emf.transaction.RecordingCommand; I need to override protected method doExecute(), the method definition does not contain any exception to throw but there is option that inside my code I have and exception and I want to catch it and raise it up, how should I handle this kind of exception, here I throw the message e but I'm not sure that this is the right way to do that.
I hope you will understand the issue since I think it more sophisticated that just throw E
i.e.throw the exception
#Override
protected void doExecute() {
try {
//my logic
} catch(Exception e) {
throw e;
}
}
You can always throw an UncheckedException from a method, which need not be declared in the throws clause.
So, you wrap your exception in any unchecked exception like that extends RuntimeException or even RuntimeException itself.
try {
//my logic
} catch(Exception e) {
throw new RuntimeException(e);
}
And just for the sake of completeness, it is a bad idea to have a single catch block for Exception, which will catch all the exceptions. Rather you should have catch block for specific type of exception your method may throw.
It seems like I can't catch exceptions in my code when the method was called from the Method.invoke method. How can catch it from inside the method itself?
void function() {
try {
// code that throws exception
}
catch( Exception e ) {
// it never gets here!! It goes straight to the try catch near the invoke
}
}
try {
return method.invoke(callTarget, args);
}
catch( InvocationTargetException e ) {
// exception thrown in code that throws exception get here!
}
Thanks!
You can get the real cause of the MethodInvocationException by checking its getCause() method that will return the exception thrown from function()
Note: you might need to call getCause() recursively on the returned exceptions to arrive at yours.
Note: getCause() returns a Throwable, which you will have to check for its actual type (e.g. instanceof or getClass())
Note: getCause() returns null if no more "cause" is available -- you have arrived at the base cause of the execption thrown
Update:
The reason why the catch() in function() is not getting executed is that xxxError is not an Exception, so your catch won't catch it -- declare either catch(Throwable) or catch(Error) in function() if you don't want to declare all specific errors -- note that this is usually a bad idea (what are you going to dio with an OutOfMemoryError?.
One reason that you can't catch UnsatisfiedLinkError with Exception is that UnsatisfiedLinkError is not a subclasses of Exception. In fact, it is a subclass of Error.
You should be careful about catching Error exceptions. They almost always indicate that something really bad has happened, and in most cases it is not possible to recover from them safely. For instance, an UnsatisfiedLinkError means that the JVM can't find a native library ... and that whatever depended on that library is (probably) unusable. Generally speaking. Error exceptions should be treated as fatal errors.
MethodInvocationException means you're calling the method wrong, it shouldn't have even gotten to inside your try block. From the docs:
Signals that the method with the specified signature could not be invoked with the provided arguments.
Edit: That's if this is the Spring MethodInvokationException, the Apache Velocity one does wrap function exceptions.
You throw exceptions as normal. The fact its inside an invoke makes no difference.
public class B {
public static void function() {
try {
throw new Exception();
} catch (Exception e) {
System.err.println("Caught normally");
e.printStackTrace();
}
}
public static void main(String... args) throws NoSuchMethodException, IllegalAccessException {
Method method = B.class.getMethod("function");
Object callTarget = null;
try {
method.invoke(callTarget, args);
} catch (InvocationTargetException e) {
// should never get called.
throw new AssertionError(e);
}
}
}
prints
Caught normally
java.lang.Exception
at B.function(B.java:15)
... deleted ...
at B.main(B.java:26)
... deleted ...
I'd like to catch an exception, log it, set a flag, and the rethrow the same exception
I have this code:
public Boolean doJobWithResult() {
boolean result = true;
final Feed feed = Feed.findById(feedId);
try {
feed.fetchContents();
} catch (Exception ex) {
result = false;
Logger.info("fetching feed(%d) failed", feedId);
throw ex;
}
return result;
}
But eclipse complains at throw ex, telling that "Unhandled exception type Exception", and suggests me to add a try-catch block around it.
In fact, I want the process calling this method to handle the exception, and not handle it myself... I just want to return true if everything goes ok, and log it if there's an exception
On the other hand, I can wrap the exception inside another exception, but I can't throw the same one..
any idea?
I think there are various things to mention here:
You either want doJobWithResult() to return true on success and false on failure, or return nothing on success and throw an exception on failure.
Both at the same time is not possible. In the first case, catch the Exception, log it and return false, in the second case change your signature to return void and throw an exception and handle it in the caller.
It's a Don't to catch an exception, log it and rethrow it. Why? Because a potential caller of your method does not know that you are already logging it, and migh log it as well.
Either throw an exception (in which case the caller has to deal with it) or catch it and handle it (log it).
Note that throwing Exception does not give the caller of your method any clue about what might potentially go wrong in your method, it's always better to throw more specific exceptions, or to wrap an exception in a user-defined one and rethrow it.
Moreover, if you throw Exception, a caller might be tempted to catch Exception without noticing that this will also catch every RuntimeException (since its derived from Exception), which might not be desired behavior.
Your doJobWithResult method needs to declare that it can throw Exception:
public Boolean doJobWithResult() {
becomes
public Boolean doJobWithResult() throws Exception {
You can throw the same exception if you add throws Exception to your method signature.
Otherwise you can throw a RuntimeException.
public Boolean doJobWithResult() {
boolean result = true;
final Feed feed = Feed.findById(feedId);
try {
feed.fetchContents();
} catch (Exception ex) {
result = false;
Logger.info("fetching feed(%d) failed", feedId);
throw new RuntimeException(ex);
}
return result;
}
In such a case, you won't need to indicate that public Boolean doJobWithResult() throws something but make sure you handle it properly later on (catch or expect your thread to stop... it's a RuntimeException afterall).
Since Exception is checked, an alternative to catching the Exception is to declare your method as throwing it:
public Boolean doJobWithResult() throws Exception {
// ...
}
If doJobWithResult doesn't have to handle the exception, then remove the catch block and add "throws Exception" to the method signature. The exception logging can be done in the class/method that have to deal with the Exception in a corresponding try/catch block.
There is no need to set the result as false in the catch block, as the value won't be returned(as we are throwing an exception).
Your method should also declare that it throws an exception and so the client will be forced to handle it.
Also consider using a more specific exception which will be thrown in this particular case.
Add throws Exception to your method. You also don't need to add result = false; in your catch block.
I think the way you handle this exception is really appropriate if any failure of feed.fetchContents() method cannot be recovered. (Idea is better to halt rather than continuing)
Apart from that I would suggest you to use more specific exception hierarchy.
And another thing I got from effective java book is if you write such a method you must document with #throw (in comments) with the reason.
You could throw an unchecked exception
Logger.info("fetching feed(%d) failed", feedId);
throw new RuntimeException(ex);
I spent the last hour looking for it since not even the Complete Reference book mentions this explicitly: unhandled throw ThrowableInstance works only with unchecked exceptions.. And only runtime exceptions are unchecked. By unhandled I mean something like this:
class ThrowDemo {
static void demoproc() {
try {
throw new NullPointerException("demo");
} catch(NullPointerException e) {
System.out.println("Caught inside demoproc.");
throw e; // re-throw the exception
}
}
public static void main(String args[]) {
try {
demoproc();
} catch(NullPointerException e) {
System.out.println("Recaught: " + e);
}
}
}
This example is taken verbatim from the Complete Reference book (9th edition).
The first throw statement i.e throw new NullPointerException("demo"); is handled by the following catch block, but the second throw statement i.e. throw e; is unhandled by the demoproc() method. Now this works here and the above code compiles successfully because NullPointerException is a runtime/ unchecked exception. If the e instance were a checked exception or even an Exception class instance then you'd get an error saying the exception e is unhandled and you'd either have to handle it within demoproc() or you'd have to explicitly declare that demoproc() throws an exception using throws in the method signature.