|
|
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 [^]
|
|
|
|
|
I am really very sorry Uwe, but that is not what Jon meant to say there.
This method would always return a true, or a false, so there won't be any need to use a try catch because now the only problem that might be encountered is a parameter in a non-string format. Which, I know, you never will do.
This method does all of the exception handling in itself and returns either a true value, indicating that the file does exist otherwise a false value indicating multiple situations, file not present, permissions do not allow reading file etc.
So, using a try catch around File.Exists function would always be a very stupid idea.
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
|
Just because the file exists when you check doesn't mean you can open it a moment later, so use both.
if(File.Exists("<location>"))
{
try
{
}
catch (Exception)
{
}
}
In most cases I don't bother checking Exists -- it's often a needless duplication of effort.
|
|
|
|
|
Sorry for disagree, but if that is the case then it would be a lot better to use the try catch as the parent block, because we're going to catch any error, then why only write it to wrap a single line (or a couple of lines) that might through exception. I would make it to be like this,
try {
} catch (Exception er) {
}
This would make much sense for your point too, a file might not be available on the next instance.
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
|
Yes, I would eliminate the Exists.
|
|
|
|
|
"by using a try catch block", that was to be added too. 
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
|
None of the above mentioned.
I do use exceptions for catching truly exceptional errors, such as COM-objects dying during usage or that SQL Server crashes during a query.
|
|
|
|
|
So, the option should be: other (please enumerate).
|
|
|
|
|
SQL Server crashing is not an exception for a client making a query. It will return some "XY123", SQL_E_NOCONN or something. Reconnect.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
