Discussions

General J2EE: Java need only one Exception (Runtime) type

  1. Java need only one Exception (Runtime) type (2 messages)

    I wrote an exception which looks like: class OnceForAllException extends RuntimeExcepion { public String code; public String category; public String message; public String[] parameters; } Since I wrote this exception, I never seem to need write another exception. This exception has a few key benefits: 1. unchecked (runtime) exception: I am a believer in unchecked exception. I totally agree that checked exception does not scale and can't be used inside a framework. 2. I18N support: you can map category to an I18N bundle, parameters are used to hold parameters that are independent of i18n strings. Of course when catching (handling) an exception, instead of using mutiple catch blocks, I have to use if/else/... inside a catch block. But I think this is an advantage because lots of times you want to do something common to some or all the exceptions you are trying to handle (catch). For example, suppose you have to rollback db transaction for some exceptions, instead of doing: ... } catch(FirstExcetion ex) { conn.rollback(); throw ex; } catch(AnotherExcetion ex) { conn.rollback(); throw ex; } catch(ThirdExcetion ex) { conn.rollback(); throw ex; } ... I will do: ... } catch(OnceForAllExcetion ex) { if (ex.getCategory().equals("cat1") && (ex.getCode().equals("code1") || ex.getCode().equals("code2") || ex.getCode().equals("code3") )) { conn.rollback(); } throw ex; } ... Of course, if conn.rollback() is some complex operation, it is very hard to organize your code elegantly using just catch blocks. Someone might say you lose the benefit of type check. But if your exception hierarchy is runtime only, your IDE or compiler won't complain if the exception is missing anyway. Auto-code-completion can be accomplished by defining code and category as string constants. I bet you can't create an exception class for every error condition in your software but you sure should use code for each error condition no matter how weird the error might be. An exception message is never good for exception handling. Codes are much more scalable than exception classes. They are used in operating system calls, DBMS etc. They are more friendly to internationalization too. Now I have a few questions: 1. Do you think one exception is enough? Could you list your reasons no matter you agree or disagree? 2. Do you write an exception class for every error condition? Does it scale? If not, do you use error/exception code? Do you have an alternative solution? Thanks.
  2. Of course when catching (handling) an exception, instead of using mutiple catch blocks, I have to use if/else/... inside a catch block. But I think this is an advantage because lots of times you want to do something common to some or all the exceptions you are trying to handle (catch).
    This would only be true if your exception hierarchy didn't naturally fit (which is obviously possible)?
    Someone might say you lose the benefit of type check. But if your exception hierarchy is runtime only, your IDE or compiler won't complain if the exception is missing anyway.
    However, personally I'd much rather just stick with a more OO style using the standard try, catch, solution. Worst case should only be a replication of a method call in your catch blocks with the given example?
  3. I do agree YOU never need to write another one. But what about while you are distributing your apis. BusinessExceptions should never never never extend RuntimeExceptions. The purpose of runtime exception is different. Even following code block can throw null pointer exception under circumstances. If you can figure out when then you will feel the need of checked and unchecked exceptions. if(str!=null){ System.out.println(str.toUpperCase()); }