In a Java program I am currently getting "Unhandled Exception" at a certain point in the program and I can't seem to determine the location where this is being generated.
Its also difficult to debug the code as the program contains streams that handle wireless data bytes sent and received. I can't seem to simulate that with a debugger.
What strategy should I adopt to locate the Exception?
Implement the Thread.UncaughtExceptionHandler interface and use setDefaultUncaughtExceptionHandler() to set it.
Sample program as courtesy. If you use multiple threads you also could just set the handler on threads you suspect to be the culprits.
public class Test {
public static void main(String args[]) {
new Test();
}
public Test() {
Thread.setDefaultUncaughtExceptionHandler(new MyUncaughtExceptionHandler());
// or if a default handler is set you can also use setUncaughtExceptionHandler
// check the javadocs for the specifics
throw new RuntimeException ("You can't get me or can you?");
}
class MyUncaughtExceptionHandler implements Thread.UncaughtExceptionHandler {
public void uncaughtException(Thread t, Throwable e) {
System.err.println ("Uncaught exception by " + t + " caught:");
e.printStackTrace();
}
}
}
You could put a try-catch(Exception ex) block around sections of code and move it around/tighten the block and have it log the exception being thrown. As long as there isn't too much code you should be able to track it down in a few runs.
But as I run the program the device
shows "Unhandled Exception" and asks
me whether to close the app.
First you need to find the place in the code that is generating this message. It sounds like the app has a GUI or whatever, so it is possible a Dialog of some kind.
Next, find the place in the code that is causing the message/dialog to be created. It is likely to be either
a try / catch block that catches Exception or Throwable, or
an UncaughtExceptionHandler.
In either case, the next thing is to add some code to cause the app to output a stacktrace for the uncaught exception. Assuming that ex holds a reference to the exception object:
ex.printStackTrace();
will write a stack trace to the standard error stream; e.g. the "console". (There are more heavy-weight solutions if you cannot find where "console" output goes to.)
Sounds like you've got an unchecked RuntimeException happening somewhere. You could easily try it in your main() method with try { } catch(Throwable t) { t.printStackTrace(); }
Or if you remotely debug it with an IDE like Eclipse, you can set it up to trigger the debugger on a Java exception breakpoint with "Suspend on uncaught exceptions". Some docs here.
If you don't have a stacktrace, you can't do much.
If it is actually caused at the other side and you received this as a message, then you should ask the other side for a stacktrace or similar information.
Edit: you should of course ensure that your own code isn't swallowing exceptions like as:
} catch (Exception e) {
// Do nothing.
}
or
} catch (Exception e) {
System.out.println("Error");
}
or
} catch (Exception e) {
System.out.println(e.toString());
}
To get the most information out of exceptions, you should do at least:
} catch (Exception e) {
e.printStackTrace();
}
or just
} catch (Exception e) {
throw e;
}
Hope this helps.
Related
i have a weird question. i had a quiz in my class today. One portion of the quiz was to find and correct errors in a short piece of code. one of the questions was like this
class Example {
public static void main(String[] args) {
try {
System.out.println("xyz");
} catch (Exception e) {
System.out.println("Exception caught");
} finally {
System.out.println("abc");
}
}
}
I thought there was no error in the program but my professor insisted that there was. Can anyone guess what the error is?
The "error" may be that you don't need to handle any exception here: System.out.println does not specify any checked exception. It could simply be:
public static void main(String[] args) {
System.out.println("xyz");
}
Since the Exception class covers both checked and unchecked exceptions, then if you add a catch block here, in this case you would be handling only unchecked exceptions, which you should not normally handle.
There is no Error in the Above Program , but also there is no need to put a try{} catch{} ....since you don't use any code that can throw an Exception , for example a risky method like Thread.sleep();
So maybe that’s what your professor meant .
Well, I see nothing that would keep this from compiling, but I do see some problems. To begin with, there are comments indicating the presence of code which is not there. Comments out of sync with code is always a problem.
[EDIT: indentation errors have been edited away] And you're catching Exception e, which you really oughtn't to do. You should always catch a specific exception that you expect to encounter, and handle it specifically. Since there's no exception that System.out.println can throw, this would make the whole Exception handling block a problem.
The following code snippet would throw a compilation error if used with IOException, since System.out.println would never throw an IOException but could throw Exception or Throwable which is its super class.
try {
System.out.println("xyz");
} catch (IOException e) {
//simple display error statement here
} finally {
//simple print statement here
}
I understand the basic try-catch, where we put methods that could possibly throw exceptions in the try block. But when we need to check if something is wrong, and throw an exception, is it correct to use the code below? And the exception is caught, the program will continue to execute?
I can't tell why the try is needed here, but without it eclipse says 'syntax error'. Thanks for your help in advance!
public run (){
if (something !=true) {
try{
throw new Exception();
}catch (Exception e){
}
Yes that is correct. You have to use try since that is where the exception-throwing code is entered and where exceptions are caught (just using a catch block won't serve any purpose)
Generally speaking, exceptions are used to let the calling code handle errors in your method.
If you just want to handle the error in run, you don't need exceptions:
public void run() {
if (something != true) {
// handle it
}
}
If you want the calling code to handle the error instead, this is where you need exceptions:
public void run() throws Exception {
if (something != true) {
throw new Exception();
}
}
And where you call run, use a try/catch block:
try {
run();
} catch (Exception e) {
// handle it
}
It is also recommended that you don't throw an Exception instance, use a custom subclass instead.
This is what I have:
#Test
public testSendMessageToStub() {
// under the hood sends message
// if exception occurrs
// it will be catched and message will be put on retry
object.sendMessage();
}
Is there any way to mark test as failed if exception has occurred but was handled in catch block in the sendMessage() method?
Thanks
EDIT: It seems like I was too fixated on these legacy tests and how they were used, that totally missed the fact of sendMessage returning a response with a status code (!!!). So now I just assert status codes, can expand these tests into more detailed scenarios and spin them on jenkins. I would like to avoid to answer how these tests were checked previously. The thought to check for status codes came to me after reading Plux's answer. Thanks!
Exactly what you are looking for is not possible with JUnit as far as I know.
If you really would want to test this, you could store some information about the exception in the catch-block where it is handled in the sendMessage() method.
A better option, in my opinion, could be to test the output or state of the object. If the state/output is exactly the same as when an exception doesn't occur, then whats the point of testing it? Do you have an overly broad catch-block?
EDIT: To AdityaTS, I dont have enough reputation to comment on a post, but my comment: you have not supplied all the code, so I can not say for sure, but my guess is that its the Logger.getLogger IN the catch-block that casts the ClassNotFoundException. (Either that or loadConnectionInfo()) see http://docs.oracle.com/javase/7/docs/api/java/lang/ClassNotFoundException.html
You cannot do this without modifying sendMessage method. If for example you catch the exception there but choose to ignore it and just return some value, code outside of the method doesn't know it. You can get around this by refactoring the code of object: move the code that handles the exception to a separate method, called e.g. handleException. Then, in your test you can create a subclass where handleException will execute the original handleException from superclass, but additionally set some flag which you will be able to read in your test and in this way tell that the exception was thrown. However, if you cannot modify the code for object's class, I'm afraid you're out of luck.
So you expect the exception to propagate out of the sendMessage() method, right?
This is another way to write a test that verifies an exception you expect will be thrown.
#Test (expected = MyExpectedException.class)
public testSendMessageToStub() {
// under the hood sends message
// if exception occurrs
// it will be catched and message will be put on retry
object.sendMessage();
}
And it's usually best to be as specific as possible (e.g. MyExpectedException.class over Exception.class)
The exception generated in the sendMessage() class will be available in the test method. Add a try catch block around the sendMessage() method like this
#Test
public testSendMessageToStub() {
try
{
object.sendMehssage();
}
catch(Excpetion e) //Use more specific exception type if you know
{
fail(e.getMessage());
}
}
I have tried this in my code. It worked for me. Let me know.
public DBConnectionInfo connectionInit()
{
loadConnectionInfo();
try
{
Class.forName(dbObject.getDriver());
} catch (Exception e)
{
Logger lgr = Logger.getLogger(PostgreLocationManager.class.getName());
lgr.log(Level.SEVERE, e.getMessage(), e);
}
try
{
dbObject.setConnection(DriverManager.getConnection(dbObject.getDatabaseURL(), dbObject.getUserName(),
dbObject.getPassword()));
} catch (Exception e)
{
Logger lgr = Logger.getLogger(PostgreLocationManager.class.getName());
lgr.log(Level.SEVERE, e.getMessage(), e);
}
return dbObject;
}
The test case for the above class.
#Test
public void testDriverFailure()
{
when(dbModelObject.getDriver()).thenReturn("driver");
when(dbModelObject.getDatabaseURL()).thenReturn("jdbc:postgresql://127.0.0.1:5432/testdb");
when(dbModelObject.getUserName()).thenReturn("postgres");
when(dbModelObject.getPassword()).thenReturn("postgres");
try
{
dbConnector.connectionInit();
} catch (Exception e)
{
assertTrue(e instanceof ClassNotFoundException);
}
verify(dbModelObject).getDriver();
}
Hopefully I can explain this clearly. If I have a main method with lots of steps that can generate different exceptions, some fatal, some not, do I have to catch the "recoverable" ones separately? It seems like that would result in potentially a lot of try/catch blocks, like so:
public static void main (String[] args) {
try {
//...
for (int i=0;someArray.length;i++) {
try{
System.out.println("I = " + i);
doSometing(i);
} catch (RecoverableException e) {
//recover, continue, whatever
//log warning
//keep
}
}//end for loop
try {
doSomethingElse();
} catch (AnotherRecoverableException e) {
//not fatal, keep on chugging
}
//...
//do more stuff that can throw unrecoverable exceptions
} catch (UnrecoverableException e) {
System.out.println("I can't handle this, it's too much!");
e.printStackTrace();
}
}
Is there a better way to do this?
My patterns are to let exceptions propagate when they would represent programming bugs and handle them as closely to the "problem" when you can handle them.
The problem is that many potential Programming bugs throw checked exceptions which is really bad (Checked exceptions are kind of a failed experement, the newer languages have gotten rid of them).
So:
Handle checked and unchecked exceptions that you can deal with immediately.
If you don't know how to handle a checked exception rethrow it as an unchecked exception.
any "top level" loop like in main or a thread should be surrounded by a try/catch/log of "Exception" to ensure that any exception that bubbles up doesn't kill the thread (but log it loudly because it represents an unknown programming bug!)
Any critical loop that should continue regardless of exceptions should have a try/catch/log of "Exception" inside the loop construct so it will continue.
Catch exception, not throwable at this high level. Throwable includes unrecoverable exceptions that you probably never want to catch.
If you really must throw an exception you think you want the caller to catch (try to avoid this--It means you are using Exceptions as code flow!), throw an unchecked exception but document it and have the method "throw" the unchecked exception (it doesn't HAVE to be handled, but this acts as additional documentation/hint).
Just as a background for why I dislike checked exceptions so--it makes code like this happeen:
try {
Thread.sleep(1000);
} catch(InterruptedException e) {}
This can hide some INCREDABLY annoying to find program-flow related bugs. In this case it simply means you might have some thread-control issues, but in others it can mean your code-flow "Magically" vanishes mid-method with no indication whatsoever (because an exception was picked up by a higher level try/catch).
If you are using Java 7 then you can club exceptions in the catch block using pipe as separator. This will reduce your number of catch blocks. But you need to decide how you want to handle them by putting appropriate code in the catch block.
In Java 7, you can do this:
try
{
...
}
catch(Exception1 | Exception2 | Exception3 e)
{
//Handle
}
catch(Exception4 | Exception5 | Exception6 e)
{
//Handle differently
}
You can use. defaultUncaughtExceptionHandler, but it only triggers if the Thread doesn't have a uncaughtExceptionHandler set.
For java versions other than 7, a cleaner approach is to handle exceptions in called methods. This makes code readable as shown below:
doSomething(int i){
//code
try{
//code
}catch(Exception1 e1){
//handle
}
catch(Exception2 e2){
//handle
}
}
doSomethingElse(){
//code
try{
}catch(Exception1 e1){
//handle
}
catch(Exception2 e2){
//handle
}
}
public static void main (String[] args) {
for (int i=0;someArray.length;i++) {
doSometing(i);
}//end for loop
doSomethingElse();
}
I do not recommend using generic Exception to catch all errors in one block. This makes difficult to know specific exceptions and prevents specific handling of them.
I am currently working on the maintenance of a piece of code that is a little bit "Exception Happy." Basically, ever method or anything throws Exception. I'm going to work to take care of that, but, in the meantime, I am wondering what is the best way to handle individual exceptions within a smaller block of code, such as a method. Is it better to do something like this:
public void aMethod()
try {
//Lots of code in here. Many lines.
} catch(Exception e) {
// TODO - Handle All Exceptions, but fairly generically
}
}
Or something like this:
public void bMethod() {
try {
// One line of code.
} catch(Exception e) {
// TODO - Handle a specific Exception (may even involve rethrowing it with more information)
}
// More code.
try {
// Another line of code.
} catch(Exception e) {
// TODO - Handle another specific exception.
}
}
I realize this is a pretty basic question, but after looking at hundreds of methods with Exceptions coming out of every one, I'm starting to wonder how best to handle all of them and what a best practice may be here.
First off, you should only put code in try/catch blocks that is exception worthy. For instance, having an unexpected value is not necessarily an exception, but trying to read from a file that doesn't exist is.
To answer your main question, you should put the exceptionable code in the same try {} block and catch specific questions in order of granularity in multiple catch blocks after the main try.
//Regular code that doesn't need to be covered by a try/catch block
try {
//critical code only
} catch (NullPointerException npe) {
//Code
} catch (RandomException re) {
//code
} catch (Exception e) {
//code
}
The answer to your question is: it depends.
if the code in the try block is coherent where it makes no sense to proceed in the event of an error, the first approach is best
if the code is taking seperate steps that are relatively unrelated (parsing numbers for instance) and can be recovered without aborting the rest of the method the seconds appraoch makes sense
A general remark on the code you inherited; it sounds like exceptions are abused to pass state around, I would refactor so that exceptions are caught at the spot where they can be handled and introduce return values or attributes to handle the state.
your bMethod isn't very useful illustration. Try to reprase it. Anyway, you have two options:
catch exceptions and log them.
catch exceptions and throw new RuntimeException(ex) (rethrow a runtime exception, setting the original as a cause)
Also, you will need to differentiate between exceptions. If your system has many custom exceptions, they are probably defined for a reason, and specific behaviour is expected when one of them is thrown.
If the try/catch block isn't adding useful information, just allow the method to throw the exception and have it handled where the caller can sensibly do something with the exception. This could cut down the number of try/catch significantly (by an order of magnitude).
BTW a trick for rethrowing any exception is.
try {
// do something
} catch (Throwable t) {
Thread.currentThread().stop(t); // rethrow any exception.
}
In addition to the suggestions already made you may also want to consider extracting try/catch blocks from the "meat" of the function.
public void delete(Page page) {
try {
deletePageAndAllReferences(page);
}
catch (Exception e) {
logError(e);
}
}
private void deletePageAndAllReferences(Page page) throws Exception {
deletePage(page);
registry.deleteReference(page.name);
configKeys.deleteKey(page.name.makeKey());
}
private void logError(Exception e) {
logger.log(e.getMessage());
}
This lets you focus your attention on the function you are really interested in without the exception handling getting in your way.