@VGR said:
@brazzy said:What if there's not really anything very useful I can do about those exceptions deep down in the application and I *want* them to propagate to somewhere near the top where I can handle them generically?
Okay, you got me there. When exactly would you want to handle all those exceptions in the same way? And if you really do have a reason do that (which is unlikely), I would think you'd just want to catch Exception.
When I can't do anything useful about those exceptions, what am I supposed to do? Log the exception, return an error code to the client / show and error dialog to the user, and get the app into a stable state. Since this is generic behaviour, I want to do it in one place only.
And of course I'd be catching Exception, but that still leaves me with methods that either declare lots of different checked exceptions or "throws Exception", neither of which is desirable.
@VGR said:
@brazzy said:I very much doubt I am supposed to scatter code all over my application that rewraps exceptions and have nearly every method in the app declare that it "throws MyAppException". If there were no checked exceptions, It would have pretty much the same effect except for the need to rewrap exceptions and declare something generic (neither of which achieves anything useful).
Yeah, actually, that's exactly what you're supposed to do. What do you think ParserConfigurationException is doing? Probably wrapping an IOException or ClassNotFoundException. Why do you think Java added the "cause" property to the Throwable class?
What is gained by wrapping an IOException into a ParserConfigurationException? Nothing. Maybe someone thinks I'm supposed to that. I think they're wrong. The "cause" property is a band-aid to the problem of wrapped exceptions losing stack trace information - it would be unnecessary if you didn't wrap the exception in the first place.
@VGR said:
But you're right that you're not supposed to have nearly every method in the app declare that it throws MyAppException. The application is where you're supposed to catch the exceptions and present the user with something more useful than "Got exception: " + exception.
In my experience, the occasions where you can do anything more useful other than beautifying it a bit and adding context information are few and far between.
@VGR said:
Does twenty years count as "much real world programming experience"? In reality, if other people's code is throwing exceptions, then either you violated the contract of the API you were calling, or there is a bug in that code and you should be giving the author of that code hell until they fix it.
Certainly the problem should be fixed, but that does not mean you have to let the program crash.
@VGR said:
In reality, a customer's data will be lost regardless of whether the runtime exception is caught.
Some data may be lost, but that does not mean there's no point in trying.
@VGR said:
In reality, catching runtime exceptions and adopting a "move along, nothing to see here" policy will make things worse:
False dichtomy.
@VGR said:
the program won't be behaving properly, and the errant behavior may go unnoticed for weeks or months, because regular users won't be sure if it's a problem at all.
So your idea of quality software engineering is making the users suffer the worst possible consequences of errors in the hope that this increases the likelyhood of bug reports?
@VGR said:
And the reality is that catching and logging the exception without
doing anything else is of almost no value. In reality, no one regularly
checks the logs of deployed programs unless they're looking for a
problem.
But users who get an error dialog and the chance to save their data are much happier than users who have their app crash. And if the error prevents them from doing something they want, they're just as likely to file a bug report.