Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

When do you write your exception handlers?

Tags:

exception

At what point during development do you typically implement your exception handlers? Do you write them at the same time as you write the surrounding code, or do you write your code and then come back to "harden" it later?

I typically do the latter so that I can see exactly where and how my code fails, but I worry that my code isn't as resilient as it could be if I would have written the exception handlers right away.

At the same time, I don't want to spend a whole bunch of development time figuring out all the possible ways that my code could fail when there are other implementation details that I haven't settled on yet.

I'm curious as to how other developers do this.

Update: I just wanted to thank everyone for their answers!

like image 960
mikekol Avatar asked Mar 01 '23 14:03

mikekol


2 Answers

I either write the exception handlers immediately, or I allow the exceptions to propagate upwards. I'm a big fan of what I call the "You're Not Going To Go Back And Fix It Later, Are You?" principle. You say you will, but honestly, once you get it working, you're not going to go back and fix it later, are you? Just get it right right now! Write your exception handlers right away, or add a throws clause and make it somebody else's problem. Do the right thing right now.

But you know what, sometimes you can't. Whatever you do, do not swallow exceptions with empty exception handlers! This is evil:

try {
    connection.close();
}
catch (Exception e) {
    // TODO Auto-generated code
}

I drop kick anybody on my team who checks that in.

If you really don't know what to do about an exception and cannot add a throws clause to propagate it upwards, at least do something halfway responsible. Print a stack trace, if nothing else. It's not ideal but at least you're not hiding errors.

catch (IOException exception) {
    exception.printStackTrace();
}

Logging it via your application's logging system is better, though you shouldn't make a habit of it. It's supposed to be the caller's responsibility to handle these kinds of things.

catch (IOException exception) {
    log.error(exception, "Unable to open configuration file %s.", fileName);
}

As a last resort, you can do an end run around your throws clause by wrapping your exception in a RuntimeException. At least you're giving somebody higher up the call chain a chance to handle the error, which is normally the Right Thing To Do.

catch (IOException exception) {
    throw new RuntimeException(exception);
}
like image 172
John Kugelman Avatar answered Mar 12 '23 09:03

John Kugelman


In my exception handler I usually raise a higher-level exception. For example, when parsing a file in Python, some string, list and dict operations may raise ValueError, IndexError or KeyError. These exceptions are usually not helpful for the caller, so I write an exception handler, which raises a descriptive MyParseError. I do this at the same time when writing the method, but later, when writing the test, I sometimes make the exception message more verbose.

like image 44
pts Avatar answered Mar 12 '23 08:03

pts