Women in Technology

Article:		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.

Showing messages 1 through 2 of 2.

• 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.
  

• 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 {
  makeUser("jimbob","easypassword");
  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().
  
  -Zipwow