|
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.
|
|
|
|
|
Just inexperienced users!
New version: WinHeist Version 2.1.0
My goal in life is to have a psychiatric disorder named after me.
I'm currently unsupervised, I know it freaks me out too but the possibilities are endless.
|
|
|
|
|
Exceptionally inexperienced users?
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
|
|
|
|
|
or commonly referred to as ESP Exceptionally Stupid People, or here in the south we just call them challenged.
New version: WinHeist Version 2.1.0
My goal in life is to have a psychiatric disorder named after me.
I'm currently unsupervised, I know it freaks me out too but the possibilities are endless.
|
|
|
|
|
Thick as a brick.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
|
|
|
|
|
Quote: But your new shoes are worn at the heels and
Your suntan does rapidly peel and
Your wise men don't know how it feels to be thick as a brick.
New version: WinHeist Version 2.1.0
My goal in life is to have a psychiatric disorder named after me.
I'm currently unsupervised, I know it freaks me out too but the possibilities are endless.
|
|
|
|
|
Or inexperienced developers!
|
|
|
|
|
If I had seen them coming, I would have handled this case before any exception would be raised. And when an exception comes, it will be logged. In most cases the current operation will also be aborted. Often the code to recover and continue after an error gets far more complicated than what it is worth.
The second and more important part is what you do with the log entries.
If the error is avoidable (like checking for null references), then you can turn the unexpected error into an expected and handled case. In the future there will be no more exceptions because of this.
In other cases you may be able to avoid the error by handling it in some way. You may, for example, wait a short time and retry a few times when a resource is temporarily blocked.
Last, there are the cases you can't do anything about. They are certainly unexpected. Why would you try to access something while expecting it not to work? Whatever has happened, it took place outside of your application and usually without prior notice. All you can do is to document the events in your log.
Proper testing can eliminate most of the first two types, leaving only the third. Exceptions are fine to assure that errors are logged and not swept under the rug. Then see to it that all errors appear only twice in the logs: For the first and the last time.
Only for the validation of user inputs I would use a more interactive approach than exceptions and logging. Actually, I don't see failed validation as an error. To me it's more a form of application logic that iterates over the user submitting input and validating it until it meets the requirements, whatever they may be. It's not unexpected, nor is this exceptional.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
