|
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.
|
|
|
|
|
I would never try to create a software application where the application starts with a try catch block and ends with a try catch block having multiple other try catch blocks. Where is the software in there? Every idiot can write a software, if the softwares were able to handle themself correctly. The need of a programmer is to understand and then write application, not to simply just apply a try catch and let the OS or the machine itself deal with the problem, it is just like:
- Son: Dad, there is a lizard in my room!
- Dad: Son, try catching it. It will resolve the problem.
I myself do not like to use a try catch block, where ever possible. Since there was an option of Files, I personally use
if(File.Exists("<location>")){
}
instead of
try {
} catch (Exception) {
}
The first code seems better and more understandable, instead of the second one, which makes very less or atleast takes C# 6 to allow conditions in catch statements. So wrapping those statements whose data (or result) you know like existence of file, data type of data, you should always use an if...else statement.
However, it would be a good approach to wrap such statements, which involve unexpected errors, such as network failure, there you need to use try catch statements, because error might be raised or it might not be.
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
|
Actually File.Exists is a special case where a try..catch might be useful.
See this SO posting [^]
|
|
|
|