|
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."
|
|
|
|
|
Most of these could be exceptions in some circumstances, but in other circumstances an app should check.
For example, usually I'd check and handle a file not existing, but if that file is a crucial resource for the app and the app cannot continue reasonably without it, that's an exception.
Except bad user input - that should always be checked.
In other words, there's an exception to every rule (except the bad user input one, but that's an exception to this rule).
(Edited to allow adding a bad attempt at a joke  )
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
I am spending a lot of time currently writing little utility applications for moving data about. I always run them through the debugger in VS so rarely put any try catch blocks in there as I want to jump straight into the debugger if any are thrown.
|
|
|
|
|
For me is a consistent way to handle errors.
My best-practice is to separate them into two groups: Technical and Business.
These two types are actually represented by two classes that inherit from Exception.
With this we can, on a higher level, decide how to notify the user.
Usually a TechnicalException will go to a "Contact the support" or "Try again later" kind of message, while a BusinessException will clearly notify the user what went wrong and what he must do to correct the issue.
I usually also like to class my exceptions with codes, HTTP style.
This helps me solve localization issues and simplifies logging.
Cheers!
|
|
|
|
|
Ditto. And I have also used the distinction between User-layer errors and system errors. A global error (exception) handler can then decide how to present the error - or log it, or pass it on.
Now, if only "exceptions" were named "structured error handling" instead then I believe we would have a more fruitful discussion. Truly exceptional events are so rare that it doesn't make sense to have a whole lot of machinery built into languages to handle them. E.g. if even out-of-memory is not a truly exceptional event - as it has been argued - then why bother having all that stuff built in to handle it ?
So - can we try to think of this as "structured error handling" instead ? And in that case I will stand firm and say that it makes perfect sense to apply it to all the examples listed.
And I say "apply it" - 'cause you should rarely, if ever, attempt to catch exceptions. Catching exceptions without re-throwing should only be done at the very top-level of your application. Otherwise, just pass it on.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
