6 ms·

This is the standard in many languages and one that I believe that java got wrong. It was a little rushed with the whole concept of forcing everyone to handle a

This is the standard in many languages and one that I believe that java got wrong. It was a little rushed with the whole concept of forcing everyone to handle all exceptions concept and building so many exceptions in for silly things like connection failures and parsing errors that reasonably can be expected to happen constantly in the normal runtime of an application. I follow the rule in almost every language that my app should still be able to run normally if all try catches were remarked out, otherwise I should be handling something better. Exceptions are expensive and don't always back out nicely when they unwind in most languages. In Objective-C, we play C rules more often then not and almost never use exceptions (except for assertion exceptions). Rather most errors have a ( out NSError ) pointer if they need to pass up errors. In Python, it's more pythonic to ask for forgiveness than to check before hand so exceptions happen all the time. I'm not sure how I feel about that though but it seems to work well enough.

dolbz 15y ago
> It was a little rushed with the whole concept of forcing everyone to handle all exceptions Just to clarify, Java doesn't force you to handle all exceptions (maybe it did at one point in time?). Exceptions which inherit from RuntimeException are unchecked and you can choose whether to handle them or not. Exceptions which don't inherit from RuntimeException are checked
- Sandman 15y ago
  That being said, I'd like to quote these passages from the official Java tutorial: "Generally speaking, do not throw a RuntimeException or create a subclass of RuntimeException simply because you don't want to be bothered with specifying the exceptions your methods can throw. Here's the bottom line guideline: If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception." Anyway... you don't need to neccessarily handle exceptions even if they are checked (in cases where it doesn't make sense that your code handles them). Add a 'throws' clause and let the calling code handle them. So the poster of the grandparent comment really got it wrong when it comes to Java and exceptions.
  - dolbz 15y ago
    > you don't need to neccessarily handle exceptions even if they are checked (in cases where it doesn't make sense that your code handles them). Add a 'throws' clause and let the calling code handle them. The problem with this is it affects the signature of all methods in your call hierarchy up to the point where it's handled as you're forced to declare that you throw exceptions. A simple change in one class could quickly become a breaking change involving several classes just because an exception can now occur.
regularfry 15y ago
Ruby also gets it wrong in several common cases. The IO libraries throw exceptions on expected events, for instance, and there are a couple of places where I flat-out disagree with the Exception class hierarchy.

dolbz 15y ago

> It was a little rushed with the whole concept of forcing everyone to handle all exceptions Just to clarify, Java doesn't force you to handle all exceptions (maybe it did at one point in time?). Exceptions which inherit from RuntimeException are unchecked and you can choose whether to handle them or not. Exceptions which don't inherit from RuntimeException are checked

Sandman 15y ago
That being said, I'd like to quote these passages from the official Java tutorial: "Generally speaking, do not throw a RuntimeException or create a subclass of RuntimeException simply because you don't want to be bothered with specifying the exceptions your methods can throw. Here's the bottom line guideline: If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception." Anyway... you don't need to neccessarily handle exceptions even if they are checked (in cases where it doesn't make sense that your code handles them). Add a 'throws' clause and let the calling code handle them. So the poster of the grandparent comment really got it wrong when it comes to Java and exceptions.
- dolbz 15y ago
  > you don't need to neccessarily handle exceptions even if they are checked (in cases where it doesn't make sense that your code handles them). Add a 'throws' clause and let the calling code handle them. The problem with this is it affects the signature of all methods in your call hierarchy up to the point where it's handled as you're forced to declare that you throw exceptions. A simple change in one class could quickly become a breaking change involving several classes just because an exception can now occur.

regularfry 15y ago

Ruby also gets it wrong in several common cases. The IO libraries throw exceptions on expected events, for instance, and there are a couple of places where I flat-out disagree with the Exception class hierarchy.