please verify me if I am right: when a program encounters a exception we should write code to handle that exception, the handler should do some recovery job, like rerun the program, but is not just telling us where we went wrong in real world application.
A:
It really depends on the error and how you want to handle it. In a lot of my automation systems, if something goes wrong, I want the program to send an email out with a specific error and then terminate. Other times I want to catch the error and run a different process to back out data that I had previously entered.
Sounds like you have the general idea down.
Eclyps19
2010-07-30 03:13:11
+2
A:
When you throw an exception you're saying: "Something happened and I can't handle it here. I'm passing the buck!"
When you catch you say: "Ok I can do something. Perhaps loop around and try again; maybe log an error message". You can even choose to ignore the error but that's usually discouraged.
In general the thrower captures the state of the failure and the catcher acts on the failure. In real life, exceptions don't always make error handling easier; but it helps keeps errors out of the main line code path. It's an alternate execution flow. You often hear this: "Exceptions should be used only for exceptional things."
seand
2010-07-30 03:13:46
"You often hear this: 'Exceptions should be used only for exceptional things.'"Really important. You never want to tell your program to catch an error that's expected to be thrown (well, almost never). You should always do your best to create robust code that will ONLY use the error handling when something unexpected happens.
Eclyps19
2010-07-30 03:17:31
@Eclyps19 This isn't, however, universally accepted. Python for instance will throw exceptions to terminate iteration. It depends on the idioms of your platform
cobbal
2010-07-30 03:29:51
how do I know exactly what is the unexpected thing which may happen. So, in real life do we usually define our own error types?
baboonWorksFine
2010-07-30 03:30:15
@cobbal good point. In Java and C# throwing to terminate loops is considered bad. However there are always exceptions (sorry bad pun!). I've had to throw and exc just to break out of a sax parsing task.
seand
2010-07-30 03:33:25
A:
Often times, I think the best approach is not to catch the error, especially if you don't have a specific response for the error. In general, I think the approach of "catch and try again" is flawed. The cause should be identified and corrected. You shouldn't just keep ramming into a brick wall.
recursive
2010-07-30 03:15:20
You are saying that usually we do not know exactly what kind of errors would be, or even we know there would be too much work to write all the handling code down, the re-try thing is meaningless?
baboonWorksFine
2010-07-30 03:26:20
I'm saying unless you are handling a specific type of error that has a known solution, blindly re-trying is probably worse than solving the underlying issue that might be concealed if the second attempt works. Fail early.
recursive
2010-07-30 03:45:05
+2
A:
This is a controversial topic, so I expect some to disagree with what I'm going to say.
Exceptions are for exceptional circumstances, namely, the following two classes of problems:
- Program Bug
- External Problems
In the former case, your program has gotten into a state it shouldn't be in. So you throw an exception and catch it at a level high enough where the program can gracefully continue. In general, this should be fairly high in your program. The reality is, if there's a bug in the middle of an operation, there's not much you can do to recover (after all, if you knew there was a bug, you'd fix it!). Best is to log it, let the user know and move on, if possible. Terminate the current operation, dialog, whatever, or even the whole program.
In the latter case, you are dealing with capricious and fickle universe. Things might go wrong through no fault of your own. In this case, you should try to detect errors as close to the source as you can and deal with them as best you can. If you sending an email to a flaky server results in an exception, it might be reasonable to try again (warning the user). If the database connection goes down, you could try again, but it might be better to give up and kill the current operation. It depends on how well you understand the external problems that might arise and what can actually be done about them.
If you have known error conditions, such as errors in user input or other data sources (e.g., XML parse error, user picked wrong choice on a form, etc.), it's probably best not to throw an exception, but instead gather and report the errors in a more structured fashion. In one project of mine, I have an error reporter class that can gather errors without interrupting program flow. Then those errors can be reported to the user, or logged.
siride
2010-07-30 03:24:13
I am confused that if errors happened, why we just want to log it, I mean the program should really stop and think why is the error and how to fix it instead..
baboonWorksFine
2010-07-30 03:58:44
@baboonWorksFine: does the program really know what to do? If it's a bug, the program probably can't fix itself. But you *do* need to know that the bug happened and what the conditions leading up to it were so that you can diagnose it and fix it. My point really is that if you actually can handle the error, you probably shouldn't be using exceptions in the first place, unless the code that can handle the error is usually far away.
siride
2010-07-30 05:29:22