4 ms·

Here's a great StackOverflow question/answer on this: http://stackoverflow.com/questions/4670987/why-is-it-better-to-throw-an-exception-rather-than-return-an-er

Here's a great StackOverflow question/answer on this: http://stackoverflow.com/questions/4670987/why-is-it-better-to-throw-an-exception-rather-than-return-an-error-code http://stackoverflow.com/questions/4670987/why-is-it-better-... I program in Java and I like that methods have * to declare what they exceptions they throw. This makes it very obvious from a consumer standpoint. * except for runtime exceptions

cletus 10y ago
Checked exceptions were/are one of Java's biggest mis-features (IMHO). You can't force a client to deal with exceptions. Checked exceptions ends up encouraging empty catch blocks, which is usually worse than propagating an exception.
- exception_e 10y ago
  If the method you're designing is going to throw an exception that wouldn't make sense to handle from a consumer standpoint, creating an exception that extends `RuntimeException` would be my advice. I agree that empty catch blocks are not a good idea.
  - daemin 10y ago
    It would b a good idea to catch it. Except Java has a FileNotFound exception when trying to open something, which to me should just be part of the normal control flow and is not something exceptional. That and you tend to get code that just "throws Exception" propagated all the way down to main. I know I've done it for little projects at Uni (when I last programmed in Java, 3.0 I think?)
- gpderetta 10y ago
  I'm a C++ programmer and I wish I had checked exceptions. Checked exceptions are really equivalent to an either monad, except that they look better in imperative code, especially if you lack some sort of 'do' notation. What Java lacks is a) enough compile time abstraction capabilities to inspect and parametrize exception specifications so that application specific exceptions can be forwarded through generic/framework code and b) a way to defer the checking to runtime (possibly via a special annotation) so that there would be no reason to ever write empty catch blocks.

cletus 10y ago

Checked exceptions were/are one of Java's biggest mis-features (IMHO). You can't force a client to deal with exceptions. Checked exceptions ends up encouraging empty catch blocks, which is usually worse than propagating an exception.

exception_e 10y ago
If the method you're designing is going to throw an exception that wouldn't make sense to handle from a consumer standpoint, creating an exception that extends `RuntimeException` would be my advice. I agree that empty catch blocks are not a good idea.
- daemin 10y ago
  It would b a good idea to catch it. Except Java has a FileNotFound exception when trying to open something, which to me should just be part of the normal control flow and is not something exceptional. That and you tend to get code that just "throws Exception" propagated all the way down to main. I know I've done it for little projects at Uni (when I last programmed in Java, 3.0 I think?)
gpderetta 10y ago
I'm a C++ programmer and I wish I had checked exceptions. Checked exceptions are really equivalent to an either monad, except that they look better in imperative code, especially if you lack some sort of 'do' notation. What Java lacks is a) enough compile time abstraction capabilities to inspect and parametrize exception specifications so that application specific exceptions can be forwarded through generic/framework code and b) a way to defer the checking to runtime (possibly via a special annotation) so that there would be no reason to ever write empty catch blocks.