|
Bad code and invalid parameters should be caught using an assert() statement or equivalent. The idea here is that if these bugs occur, you have a serious logic error in your code, and the program should terminate immediately - even if recovery is possible, it is no longer safe.
User input, sensor input, etc. should be validated. A user input validation error may be fixed by asking the user to correct the error.
Bad sensor input cannot be fixed, but some sort of low-level handling policy should be in place - filtering of extreme values, smoothing, etc. Only if the data are verifiably erroneous (e.g. because of a bad sensor) should an exception be thrown - this is similar to the case of a bad network connection, where no data are available. Note that if a verified reading exceeds the "safe" range, this is not exceptional; it should be handled in the normal code, just like any other reading.
A network error etc. cannot be handled at the low level - the network I/O module has no way to know whether it should retry the operation, fall back to an backup link, etc., and therefore throwing an exception is the appropriate way to handle this.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
When network is not available, you still have data: the error code (WSAENOTAVAIL or whatever subsystem reported is down).
|
|
|
|
|
Cristian Amarie wrote: When network is not available, you still have data: the error code (WSAENOTAVAIL or whatever subsystem reported is
down).
The issue here is that the O/S network API reported an error; how should this error be handled by our program?
We may, for example:
1. Retry the operation on the same network link
2. Attempt the operation on a backup link
3. Abort the transaction
4. Queue the transaction for later attempts
5. ...
The module that called the O/S network API has no idea how to proceed, and therefore an exception that transfers control to a higher level is appropriate.
This is not true, for example, for bad user input. In that case, the correct action is usually to ask the user to enter the correct data.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
So you're using exceptions in this case as a control flow. Not sure if this is the exceptions role, when a simple
SetLastErrorSuperEx(__FILE__, __LINE__, GetLastError(), L"Johnny Bravo was here.");
return false; would do the job. (SetLastErrorSuperEx left as exercise for the user).
|
|
|
|
|
No, I am not using exceptions in order to control flow. I am using them in order to:
1. Pass the error up to a layer that has the context to handle the error.
2. Ensure that the error is handled. (An unhandled exception crashes the program.)
This, IMO, is a more robust way of ensuring that errors get handled appropriately.
[Note that your SetLLastErrorSuperEx() API is often part of the exception handling mechanism. The missing parts are the stack unrolling, calling of destructors, etc. It is these (missing) parts of exception processing that make it more robust than simply returning an error code.]
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
|
All of the above
modified 10-Feb-15 2:49am.
|
|
|
|
|
I am not sure why, but this message triggered the spam filter. I passed it through the Message Moderation Queue, which is why it is saying "Modified".
Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
|
|
|
|
|
It seems that it is a duplicate, satisfying one of the criteria for spam.
I'm retired. There's a nap for that...
- Harvey
|
|
|
|
|
But I had to pick at least one anyway, otherwise I couldn't submit.
|
|
|
|
|
|
Hear hear
+5
--
The trouble with people, is that they want to hear only what they want to hear.
|
|
|
|
|
That was the answer I was looking for, but it was not in the list.
Unfortunately, depending on the language, some frame-works do not give you the option of being proactive in the prevention of exceptions being thrown.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence." - Edsger Dijkstra
"I have never been lost, but I will admit to being confused for several weeks. " - Daniel Boone
|
|
|
|
|
Every one of them "should" be handled before they become an "unexpected" exception.
Always validate user input.
|
|
|
|
|
agreed
|
|
|
|
|
ledtech3 wrote: Always validate user input
They obviously should all be handled; the question is - what is the best way to do so?
IMO, handling bad user input by throwing an exception is wrong. After validating the input, some feedback indicating what is wrong should be provided to the user, and the user should be allowed to correct the error. This UI model is not well suited to exceptions.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
They are all a little different that is the problem, so you have to handle them all in a little differnt ways.
|
|
|
|
|
They don't ask me who to hire -
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "As far as we know, our computer has never had an undetected error." - Weisert | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Can't they make an exception once every while ?
|
|
|
|
|
Yes... they hired him
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
isn't this the same as my bad code??
|
|
|
|
|
Good catch!
If My bad code means: null reference, divide by zero, index out of range etc, then Invalid Parameter values is out provided range.
|
|
|
|
|
Nice try!
|
|
|
|
|
Dennis E White wrote: isn't this the same as my bad code??
No, it is the bad code of the caller, which may or may not be your own code.
I'm retired. There's a nap for that...
- Harvey
|
|
|
|
|
try catch almost everything, unless you know that it will bubble up to a method that is trapping it.
you should have very few null reference exceptions, if at all. I use ReSharper extensively, and this issue has almost gone to zero occurrences for me, now.
If there is any logic that will be performed "external" i.e. api/service calls, then I log the exceptions. If my request back is not Ok, I log that as well.
|
|
|
|