5 comments

• 

  Sergio Bossa

  2 years ago

  Hi Johannes,
  
  thanks for your good write up about exception handling, IMHO a very hot argument.
  
  However, what you miss is IMHO how to deal with business exceptions: a very important question that may deserve a whole post ;)
  
  Probably they are those exceptions you say "you are required to deal with" ... I'd like to know more from your opinion and experience.
  
  Cheers!
  
  Sergio B.
  reply
• 

  Johannes Brodwall

  2 years ago

  Hi Sergio,
  
  Thanks for the comment. I agree with you that business exceptions deserve a whole post of its own. I would really appreciate feedback on what you'd like to read about in such a post.
  
  There are two types of exception handling strategies that I could explore more fully: Things like retrying, failing to another node or mechanism and such strategies, mostly for resource exceptions. Then there is "what to do when you get an AccountOverDraftException, NumberFormatException, AuthorizationFailureException etc." I assume it is the latter you are refering to?
  
  ~Johannes
  reply
• 

  Bjørn Bjerkeli

  2 years ago

  Good writeup Johannes, what could be interestning as well is to add some practical examples related to common mistakes.
  
  I often encounter the issue programs failing to establish a proper context in programs that raises exceptions.
  
  Establishing such a context is trivial, but often omitted rendering the code much more difficult to debug. consider the following example of an instance method in an Account class:
  
  public void validateAcount() {
  if (isOverdrawn()) {
  throw new IllegalStateException("Account is overdrawn, balance ["+getBalance()+"], limit ["+getLimit()+"]");
  }
  
  }
  
  compared to the following version that has context (given a proper toString() implementation):
  
  public void validateAcount() {
  if (isOverdrawn()) {
  throw new IllegalStateException("["+this+"] is overdrawn, balance ["+getBalance()+"], limit ["+getLimit()+"]");
  }
  
  }
  reply
• 

  Casey Mullen

  1 year ago

  I just read "Practices of an Agile Developer" as well, and the categories do sound useful... although I am not sure how to practically express the categorization of a given exception. If i'm the thrower, I could throw my own "categorized" exception, but what about exceptions emanating from some other library?
  
  Does anyone know of any practical (open source?) project that has made practical, explicit use of these (or similar) categories? Or are these categories more theoretical than practical?
  reply
• 

  Johannes Brodwall

  1 year ago

  Good questions, Casey.
  
  We have created subclasses of RuntimeException for SystemException and ApplicationException (should've been InvalidUsageException). Everything that is not classified is a "bug". Out top-level interceptors which log, retry etc. use this to decide the log level and retry strategy.
  
  I don't think the categories I propose have been used as such in any open source project. However, I think one of the best things about the Spring Exceptions, is that they allow you to decide what sort of a problem it was.
  
  DataAccessResourceFailureException tells you that the database or network is down, InvalidDataAccessUsageException tells you that the client code did something wrong, OptimisticLockFailureException is not actually an error at all (and my categories don't include it). In JDBC, these, and more, were lumped together as SQLException.
  
  I guess what I am trying to say, is that as far as I know, the categories I propose are more a description of why I think Spring has good exceptions than it is a description of what they've done.
  reply