Article:		What I Hate About Your Programming Language
Subject:		Java: Catch all exceptions?
Date:		2003-05-13 15:11:20
From:		zipwow
I wonder what the author means by: "... forcing every method to catch all exceptions that its child calls or may call can be tedious. I'd rather be able to ignore an exception and let it propagate upwards." Isn't that the description of adding it to the throws clause of your own method? -Zipwow

Showing messages 1 through 6 of 6.

• Java: Catch all exceptions?
  2003-05-13 15:27:43  anonymous2 [View]
  
  
  I believe if you change "catch" to "care about" you're closer to what the author intends, but you still have to add "non-runtime" in front of exceptions (The compiler doesn't force every method to throw or catch runtime exceptions thrown in child methods).
  
  I circumvent that behavior by declaring (almost) all of my exceptions as runtime.
  
  I don't think Java should require the addition of "throws" to the method declaration for non-runtime exceptions. It should just be implied.
  
  Does anyone have an advantage that forcing the "throws" provides?
• Java: Catch all exceptions?
  2003-05-13 19:30:50  anonymous2 [View]
  
  
  Truthfully? Java doesn't get all pissy. Thats about it. O yah, and some possible exceptions (I/O, FileNotFound) that u would normally have 2 catch, it will ignore if u throw. dunno y.
• Java: Catch all exceptions?
  2003-05-13 17:50:15  anonymous2 [View]
  
  
  You should use exception handling to indicate errors.
  
  RuntimeExceptions indicate errors in your program logic that you should fix (things like NullPointerExceptions). RuntimeExceptions are things that should NEVER happen in properly debugged code.
  
  Checked exceptions, things like FileNotFoundException are things that can reasonably happen in code AND you cannot defend against in your code (like you can a NullPointer). Checked exceptions do not indicate logic errors in your code.
  
  If the compiler did not force you to deal with checked exceptions then you would have to know what each method throws. To do this you would presumably need to check the documentation.
  
  If you are going to write "proper" robust code you are going to want to handle all errors (right?). WOuld you rather have the compiler help you out or would you rahter do things manually?
  
  One way or antoerh you should be handling all the errors - why not let the compiler help?
• Java: Catch all exceptions?
  2003-05-13 17:19:41  anonymous2 [View]
  
  
  I think the language designers wanted you to make throwing the exception part of the interface of your own function. If someone calling your function doesn't know how you implemented it, how do they know they should check for a HashTableSober exception, or somesuch? The client code shouldn't crash because of something it wasn't informed of.
  
  I think that's the idea, anyway. In practice, implied "throws" would make life more convenient.
  
  Grant_Watson on Slashdot
• Java: Catch all exceptions?
  2003-05-13 15:44:26  anonymous2 [View]
  
  
  Sure, it is always about adding a sanity check. I believe that many if not all of the non-runtime checks are brain dead and cannot be ignored without severly breaking your program.
  
  I may not get an interruption while waiting on a semaphore very often, but when it happens you better damn know that it did.
• Java: Catch all exceptions?
  2003-05-13 16:03:56  zipwow [View]
  
  
  "I may not get an interruption while waiting on a semaphore very often, but when it happens you better damn know that it did."
  
  Right, and you'd be darn sure you remember about it too.
  
  Same goes with broken inputs, bad filenames, and pretty much everything else that checked exceptions are used for.
  
  -Zipwow