Women in Technology

Hear us Roar

  Best Practices for Exception Handling
Subject:   A few things
Date:   2003-12-05 08:17:50
From:   javid
I like the article in general.

I don't agree that you shouldn't throw custom exception. You said to avoid this. In fact, I would argue the exact opposite within a Test First Design model. If you don't throw custom exceptions, you can get false positives in your unit-tests. For example, lets say you are testing that a method throws RuntimeException, because of a SQLError that you wrapped, but it instead it throws RuntimeException because of something else. Your test would still pass, but it is a false positive. If you throw a unique exception, you don't run into that problem.

Also, you seem to advise people to never deal with the exception, and always throw it. If there is a non-recoverable application failure, I think you should always throw it, and let a top-level exception handler deal with displaying the message. Otherwise, you should try to recover in the catch block if you can. For example, if you are attempting to open a file, and you can retry 4-5 times until the lock is released, then you should try to recover from the failure, not just throw the exception.

Otherwise, I think it was a good article.

Full Threads Newest First

Showing messages 1 through 2 of 2.

  • Exceptions in unit tests
    2003-12-09 10:14:00  zipwow [View]

    I felt the same way for a while, but also disliked the number of exception classes that were creeping into my API. Worse, it didn't completely solve the problem, as unless *every* throws clause was different, I could still get a false positive.

    What I did was adopt this sentiment:

    Every throws clause should construct its exception (of whatever type) with a different *message*. This is helpful anyway, since once I get an exception thrown, even if the code (like in production, say) doesn't keep line numbers, I know where it came from.

    Then, in the unit test, I wrote code like this:

    try {
    fail("user creation should fail for dictionary password");
    } catch (UserException e) {
    assertTrue("MyException did not mention dictionary password",
    e.getMessage().indexof(DICT_PASSWORD_STRING) != -1);

    I'm not handling internationalization here, but if you are, I think there's an analagous solution, probably having to do with getMessage() vs getLocalizedMessage().

  • Custom exceptions always have information for client code!
    2003-12-23 03:00:26  sebastien.couturiaux [View]

    I also disagree on the fact that you shouldn't throw custom exceptions.

    My opinion is that custom exceptions always have at least one precious piece of information for client code : their type !!!!

    Suppose I create an XYZService that can throw XYZException, simply extending RuntimeException without any additional attribute or method. The ture added value of my custom exception is that I will be able in the client code to filter exception handling precisely for exceptions coming from this XYZService.