The problem with try/catch, really, is that it makes a tremendous amount of visual noise, which makes sense for critical operations that might crash everything, but just don't make sense when you can tolerate certain errors or checking for proper output with with a conditional looks better and is more appropiate.
Obviously then you have an issue with language conventions. How do you check for the returns of a method that does an in-place modification without returning anything? What happens when Null is a proper return value? What about having to access specific members or registers to check?
Perhaps, much like logging frameworks, we may need to categorize throwable actions by their importance, or think of a new convention that can handle such things more easily.
But what is your alternative? Doesn't checking the return code of every statement also make a tremendous amount of visual noise?
I've seen C code where about 80% of the code is dedicated to error handling and corner cases. Before every statement it has to check the current error status, and after it the return value... it's almost unreadable.
With try/except/finally a lot of that can be cleaned up, by handling the errors higher-up in the call hierarchy where they make sense to handle.
I see a lot of critique of exceptions, but haven't seen one better alternative yet, at least one that doesn't require switching to an obscure programming language.
Edit: this does assume that exceptions are used properly: for errors that should bubble up, not as extra return value.
Obviously then you have an issue with language conventions. How do you check for the returns of a method that does an in-place modification without returning anything? What happens when Null is a proper return value? What about having to access specific members or registers to check?
Perhaps, much like logging frameworks, we may need to categorize throwable actions by their importance, or think of a new convention that can handle such things more easily.