Discussion on:
View:
Show:
I do not see any of this as software writing.There are certain levels in a computer that do not seem to be affected by virus.Math is one of them.
Though the article describes the mechanics of .Net exceptions, it fails to describe how to apply them. Here are some simple rules to follow:
1) Use a Finally block only when there is some non-memory element to clean up. This typically involves things like closing files or communications connections. The Finally block should call a common Cleanup (or your favorite name) that does an orderly shutdown. All shutdown operations should be "safe", i.e., check if the item is created or open before closing it or releasing it. Make sure it is extensive and covers even things you "know" will never be left in a bad state. Error processing is complex and it is better to be aggresive.
2) Only Catch exceptions at the very highest point in the code and then display them to the user.
3) Never catch and eat exceptions (ala the infamous VB on error resume next).
4) Reuse the standard System exceptions. There is usually no advantage to deriving custom application specific Exceptions.
5) Always generate a clear error message. It is usually best to generate a custom message when throwing the exception including the bad value and acceptable range of values and any other information that might be useful. There is no need to duplicate anything that is in the stack trace. Do not use a canned message or a simple error number.
6) Always test your exception generation and handling. NUnit is very useful for this.
The article is correct and special effort should be dedicated to exception handling. I hope the above rules give some additional guidance.
1) Use a Finally block only when there is some non-memory element to clean up. This typically involves things like closing files or communications connections. The Finally block should call a common Cleanup (or your favorite name) that does an orderly shutdown. All shutdown operations should be "safe", i.e., check if the item is created or open before closing it or releasing it. Make sure it is extensive and covers even things you "know" will never be left in a bad state. Error processing is complex and it is better to be aggresive.
2) Only Catch exceptions at the very highest point in the code and then display them to the user.
3) Never catch and eat exceptions (ala the infamous VB on error resume next).
4) Reuse the standard System exceptions. There is usually no advantage to deriving custom application specific Exceptions.
5) Always generate a clear error message. It is usually best to generate a custom message when throwing the exception including the bad value and acceptable range of values and any other information that might be useful. There is no need to duplicate anything that is in the stack trace. Do not use a canned message or a simple error number.
6) Always test your exception generation and handling. NUnit is very useful for this.
The article is correct and special effort should be dedicated to exception handling. I hope the above rules give some additional guidance.
in debugging when writing classes.
Special case but I was using reflection's MethodInfo.Invoke and it told me that the method had failed with an invalid argument exception. It didn't say which method though without examining the stack trace nor what argument was wrong.
After spending about twenty minutes arsing about it turned out to be from enum.parse on the 18th node of the third xml file I was reading in.
Spending that long discovering I'd spelt a node content as Indidual sort of set my teeth on edge.
If you do it though, catch the generic exception as close as possible. Throw your custom exception passing in the generic exception as innerexception so you keep the chain going.
A couple of these and on invoke I got an exception detailing the file, the id of the problem node, the enumerated type name and the problem value. Not something I'd expect to make use of in the live version, but a real time saver while developing and unit testing.
And I learnt a lot doing it as well, you never know when it might come in handy. The exception proves the rule.
Other than that I agree, anyone who writes code that swallows exceptions without taking another non default action, should be tortured to death over a an extensive period of time, by the poor git who discovers something they hadn't thought of.
Finally seems to be of less utility in .NET, most of the time you can let the garbage collector clear up resources. You still need it but no where near as much as say Delphi.
Special case but I was using reflection's MethodInfo.Invoke and it told me that the method had failed with an invalid argument exception. It didn't say which method though without examining the stack trace nor what argument was wrong.
After spending about twenty minutes arsing about it turned out to be from enum.parse on the 18th node of the third xml file I was reading in.
Spending that long discovering I'd spelt a node content as Indidual sort of set my teeth on edge.
If you do it though, catch the generic exception as close as possible. Throw your custom exception passing in the generic exception as innerexception so you keep the chain going.
A couple of these and on invoke I got an exception detailing the file, the id of the problem node, the enumerated type name and the problem value. Not something I'd expect to make use of in the live version, but a real time saver while developing and unit testing.
And I learnt a lot doing it as well, you never know when it might come in handy. The exception proves the rule.
Other than that I agree, anyone who writes code that swallows exceptions without taking another non default action, should be tortured to death over a an extensive period of time, by the poor git who discovers something they hadn't thought of.
Finally seems to be of less utility in .NET, most of the time you can let the garbage collector clear up resources. You still need it but no where near as much as say Delphi.
Good point, Tony!
Of course, the most important rule in programming is to remember to break the rules when it is justifiable. I follow my own rules most of the time, but I am not going to waste effort to follow a rule in a situation where it doesn't fit.
Of course, the most important rule in programming is to remember to break the rules when it is justifiable. I follow my own rules most of the time, but I am not going to waste effort to follow a rule in a situation where it doesn't fit.
You seen that trick where someone throws one inside a loop to break out it?
You can always tell when someone has just discovered them, code littered with exception handlers. Makes you wonder why the skipped the introduction paragraph on what they were for.
You can always tell when someone has just discovered them, code littered with exception handlers. Makes you wonder why the skipped the introduction paragraph on what they were for.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
