"david.lloyd(a)jboss.com" wrote : | "richard.opalka(a)jboss.com" wrote : | | DO NOT DECLARE TO THROW RUNTIME EXCEPTIONS | | ... | | * RULE 2.5: Runtime exceptions indicate programmer errors. The best practice is to don't declare them in method signature. | | | | Couldn't disagree more. Putting all possible/expected unchecked exception types in the throws clause gives users a sense of what to expect; also it can hint to IDEs that you might want to add a catch clause for it. And it does no real harm. | | "richard.opalka(a)jboss.com" wrote : | | * shouldn't be declared to be thrown from API if it is assignable from java.lang.RuntimeException and represents programmer error | | | | Again, disagree. | Let me disagree ;) * Runtime exceptions represent programmer errors * Checked exceptions (declared in throws clause) represent special cases user (not programmer) should deal with/know about Here's one example from String.class: The following public String(char value[], int offset, int count) constructor throws StringIndexOutOfBoundsException runtime exception. If I'd change it's signature like you suggest, i.e.: public String(char value[], int offset, int count) throws StringIndexOutOfBoundsException the working with such API would look like: char[] data = ...; | String s = null; | try | { | s = new String(data, 0, 5); | } | catch (StringIndexOutOfBoundsException e) // I'm forced to catch the exception or rethrow it | { | log.error("Damn! Man fix it, then start application again", e); | System.exit(1); | } | IMO runtime exceptions cannot be part of the signatures, because they represent my programming errors. The only way I can fix them is to shutdown application, then fix it and again start the application. I'd end with hundreeds/thousands application exit points :( View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268934#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...