I've been searching for an error handling comprehensive...
-
Yeah I've seen all of that but it's not really scratching the itch for me. But I'll just write up something on my own and plagiarize from these other sources and call it my own work. Then I'll post it on the Russian version of CP and all will be well. :laugh:
Are you looking for something like MadExcept(http://madshi.net/madExceptDescription.htm[^])? Unfortunately, MadExcept is not for .Net, but Delphi Win32. And, I've been looking for something similar for .Net, but up to now no luck. So, I might have to develop my own.
Daniel
-
Executive Summary: .NET code throws exceptions. All over the place. Exceptions are to .NET what marmalade sandwiches are to Paddington Bear. You may think there's no way a given line could thrown an exception, but look away and next thing you know, there's an exception, as if pulled from a secret compartment. Uncaught exceptions make your program crash. You don't like crashing programs, do you? Crashing programs kill cute, fluffy, kittens. You don't hate kittens, do you? I didn't think so. Therefore, you should catch all exceptions. One way to do this is to wrap your code in an exception handler, like so:
try
{
// some code
// some more code
// even more code
} catch (Exception e) {}There. That won't crash. Of course, if
some codethrows an exception thensome more codewon't run. And as we've already established, some code is pretty much guaranteed to throw an exception sooner or later. What ifsome more codeis crucial to your Business Process? Therefore, the Best way to handle errors in a C# program is to wrap every line in an exception handler:try { /* some code */ } catch (Exception e) {}
try { /* some more code */ } catch (Exception e) {}
try { /* even more code */ } catch (Exception e) {}There! Now you're safe. All errors are handled. The C# Way. For more information on this Best Practice, see my upcoming book: On Error Resume Next - Not Just for VB Programmers!
<< Crashing programs kill cute, fluffy, kittens. You don't hate kittens, do you? >> They make great play things for my dog, main reason I like them.
-
Executive Summary: .NET code throws exceptions. All over the place. Exceptions are to .NET what marmalade sandwiches are to Paddington Bear. You may think there's no way a given line could thrown an exception, but look away and next thing you know, there's an exception, as if pulled from a secret compartment. Uncaught exceptions make your program crash. You don't like crashing programs, do you? Crashing programs kill cute, fluffy, kittens. You don't hate kittens, do you? I didn't think so. Therefore, you should catch all exceptions. One way to do this is to wrap your code in an exception handler, like so:
try
{
// some code
// some more code
// even more code
} catch (Exception e) {}There. That won't crash. Of course, if
some codethrows an exception thensome more codewon't run. And as we've already established, some code is pretty much guaranteed to throw an exception sooner or later. What ifsome more codeis crucial to your Business Process? Therefore, the Best way to handle errors in a C# program is to wrap every line in an exception handler:try { /* some code */ } catch (Exception e) {}
try { /* some more code */ } catch (Exception e) {}
try { /* even more code */ } catch (Exception e) {}There! Now you're safe. All errors are handled. The C# Way. For more information on this Best Practice, see my upcoming book: On Error Resume Next - Not Just for VB Programmers!
Don't forget this scenario:
try
{
// some code
// some more code
// even more code
}
catch (Exception e)
{
try
{
// still, more code
}
catch (Exception e)
{
//um, another try...catch?
}
} -
Or you could just use the Language of the Gods: VB6. It has a construct
On Error Resume Nextthat does the same thing all that complicated fugly looking See Pound stuff does for only a single line per file.Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots. -- Robert Royall
No! No! Bad idea! On Error Resume Next came straight from Satan's loins. Help! Keep it away! The problem with On Error Resume Next is that it continues to execute the rest of the code. Let's say that your entire code is dependent upon a single ID being populated. It's not populated because it generated an error. However, that error wasn't handled, it just goes to the next line of execution. The rest of your code will have to make special cases for when the all-important ID isn't populated. Now imagine if you have five IDs. The code becomes ugly. Another special example. You have a loop that goes from 1 to 10. However, the line that increments the iterator generates an error. Your loop now becomes infinite. The worst part is no error is ever generated to tell you what is happening. It just keeps spinning until you stop it in bewilderment.
-
No! No! Bad idea! On Error Resume Next came straight from Satan's loins. Help! Keep it away! The problem with On Error Resume Next is that it continues to execute the rest of the code. Let's say that your entire code is dependent upon a single ID being populated. It's not populated because it generated an error. However, that error wasn't handled, it just goes to the next line of execution. The rest of your code will have to make special cases for when the all-important ID isn't populated. Now imagine if you have five IDs. The code becomes ugly. Another special example. You have a loop that goes from 1 to 10. However, the line that increments the iterator generates an error. Your loop now becomes infinite. The worst part is no error is ever generated to tell you what is happening. It just keeps spinning until you stop it in bewilderment.
-
Might I suggest rebooting your sarcasm detector?
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots. -- Robert Royall
DOH! I thought that might be the case, but just in case.. And let that be a lesson to anyone using On Error Resume Next :)
-
Executive Summary: .NET code throws exceptions. All over the place. Exceptions are to .NET what marmalade sandwiches are to Paddington Bear. You may think there's no way a given line could thrown an exception, but look away and next thing you know, there's an exception, as if pulled from a secret compartment. Uncaught exceptions make your program crash. You don't like crashing programs, do you? Crashing programs kill cute, fluffy, kittens. You don't hate kittens, do you? I didn't think so. Therefore, you should catch all exceptions. One way to do this is to wrap your code in an exception handler, like so:
try
{
// some code
// some more code
// even more code
} catch (Exception e) {}There. That won't crash. Of course, if
some codethrows an exception thensome more codewon't run. And as we've already established, some code is pretty much guaranteed to throw an exception sooner or later. What ifsome more codeis crucial to your Business Process? Therefore, the Best way to handle errors in a C# program is to wrap every line in an exception handler:try { /* some code */ } catch (Exception e) {}
try { /* some more code */ } catch (Exception e) {}
try { /* even more code */ } catch (Exception e) {}There! Now you're safe. All errors are handled. The C# Way. For more information on this Best Practice, see my upcoming book: On Error Resume Next - Not Just for VB Programmers!
You cats ever seen the various TypeLoadException bug discussions floating around? Microsofts own best practices states never to use exceptions for controlling program flow. This one should be in bold print and flashing neon. However, the .Net type loader uses a try...catch block to attempt to load a type from an assembly. If it catches a TypeLoadException, it tries the next assembly, and so on until it either successfully loads the type or runs out of assemblies in the search path. Ouch. In some scenarios, it can easily throw hundreds of TypeLoadException exceptions and take more than a minute to load a single type. MAC
-
I've been looking here for a thorough discussion on error handling in C# and haven't really found what I'm looking for. I need it to show to an executive team as an outline for discussion on something but I'm coming up empty on my searches. I can find "best practices" which is always a subset of the discussion and I can find old versions of libraries by Microsoft. I cannot find a current discussion that involves newer revisions of C#. Anybody see anything like that lately? Searches here show it's a dated topic that doesn't have a thorough article that really describes the entire process in depth. Searches on Google don't really pull much more than C# Corner rubbish and the typical two lines of code and 6 paragraphs of personal rhetoric about the methods and all... UGH! If you have seen something somewhere and remember well enough to recall the link I'd be grateful. It won't be used so much for code as it will be a basis for conversation with 2 other developers and an executive team on a large project that is all but devoid of error handling.
Ever try design by contract? With this ideology, your code expects certain things as input. If it does not receive valid input, it throws an exception. In turn for valid input, it will create valid output. If it does not give valid output, the original requester will throw an exception. The exceptions are generally handled via a top-level presentation handler, maybe in the form of a popup box that tells the user what the error was and where it occurred. This is useful for debugging and provides an aesthetically pleasing interface for the user and programmer.
-
You cats ever seen the various TypeLoadException bug discussions floating around? Microsofts own best practices states never to use exceptions for controlling program flow. This one should be in bold print and flashing neon. However, the .Net type loader uses a try...catch block to attempt to load a type from an assembly. If it catches a TypeLoadException, it tries the next assembly, and so on until it either successfully loads the type or runs out of assemblies in the search path. Ouch. In some scenarios, it can easily throw hundreds of TypeLoadException exceptions and take more than a minute to load a single type. MAC
Michael A. Cochran wrote:
In some scenarios, it can easily throw hundreds of TypeLoadException exceptions and take more than a minute to load a single type.
Yeah, i've seen that. There's one app i'll never start in the debugger, because VS takes enough time logging all those exceptions to add several minutes to startup. 's sad. :sigh:
-
DOH! I thought that might be the case, but just in case.. And let that be a lesson to anyone using On Error Resume Next :)
I long ago learned that lesson, helped greatly by a fellow developer who thought "none of the errors this code will produce are really going to matter." ...yes, murder being against the law and as I did at that time have some semblance of self-control, he is still breathing. He even kept his job.
-
Shog9 wrote:
.NET code throws exceptions
Some .NET code catches and hides exceptions. I was once debugging into .NET source, and I did something with a ComboBox (WinForms). I get getting a funny error, on an operation I normally often perform on ComboBoxes. It turns out that .NET basically does an empty catch in that operation, but because of my deeper debugging, it was breaking when thrown, deep inside the innocent looking combo.
It is one of Microsoft's more common teeth-gritting practices that common tasks depend on suppressing exceptions, then performing operations that would generate exceptions, then check to see if nothing happened. It is a practice that was common in all their Basic platforms (to my knowledge, this happened as far back as Applesoft Basic for the Apple II platform).
-
Your missing the key ingredient. Throw what you are doing kills the error completely unless you are able to handle it gracefully and that assumption is based entirely on whether or not it's your code. Nish's link is wrong as it's just a best practices it's not a comprehensive discussion that involves what you do with errors that are yours, errors that are 3rd party and then unknown errors that came about do to unusual circumstances that may be unique to the specific machine executing the code. ;P
-
Might I suggest rebooting your sarcasm detector?
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots. -- Robert Royall
> Might I suggest rebooting your sarcasm detector? That's actually sig quality! :-D
-- Time you enjoy wasting is not wasted time - Bertrand Russel
-
Michael A. Cochran wrote:
In some scenarios, it can easily throw hundreds of TypeLoadException exceptions and take more than a minute to load a single type.
Yeah, i've seen that. There's one app i'll never start in the debugger, because VS takes enough time logging all those exceptions to add several minutes to startup. 's sad. :sigh:
I had a problem with that for awhile. In the end I discovered that resetting my VS2008 settings back to the default would fix it. Reduced my debug time-to-run from 1-2 minutes down to just a few seconds. When I compared the exported settings files (I exported before I reset and again after the reset,) it looked like something to do with the control toolbar and how it had dynamically built the AjaxControlToolkit project I was including in my solution. MAC
-
I've been looking here for a thorough discussion on error handling in C# and haven't really found what I'm looking for. I need it to show to an executive team as an outline for discussion on something but I'm coming up empty on my searches. I can find "best practices" which is always a subset of the discussion and I can find old versions of libraries by Microsoft. I cannot find a current discussion that involves newer revisions of C#. Anybody see anything like that lately? Searches here show it's a dated topic that doesn't have a thorough article that really describes the entire process in depth. Searches on Google don't really pull much more than C# Corner rubbish and the typical two lines of code and 6 paragraphs of personal rhetoric about the methods and all... UGH! If you have seen something somewhere and remember well enough to recall the link I'd be grateful. It won't be used so much for code as it will be a basis for conversation with 2 other developers and an executive team on a large project that is all but devoid of error handling.
- Net Framework is for lazy programers who don't want to write their own code. DON'T use Microsoft's pre-fabbed datasets. Write your own "strongly-typed" dataset. Less code, fewer mistakes, smaller app. Anything you can write on your own that doesn't involved the .Net Framework is the safest way to ensure less bugs are in your app. If you need something in the .Net framework, write it yourself. 2) Oh, don't forget to use the .Net framework whenever you can, as the code is already written and you can develop apps that much faster. These people that write their own programs with all those newly programmed bugs just do that for Job Security (e.g. create a bug now that will crop up later so my programming skills are continually needed). Other than those two pieces of advise, don't forget to floss after brushing. :suss:
ASPX ~ Apple Simply Performs eXcellently
-
I've been looking here for a thorough discussion on error handling in C# and haven't really found what I'm looking for. I need it to show to an executive team as an outline for discussion on something but I'm coming up empty on my searches. I can find "best practices" which is always a subset of the discussion and I can find old versions of libraries by Microsoft. I cannot find a current discussion that involves newer revisions of C#. Anybody see anything like that lately? Searches here show it's a dated topic that doesn't have a thorough article that really describes the entire process in depth. Searches on Google don't really pull much more than C# Corner rubbish and the typical two lines of code and 6 paragraphs of personal rhetoric about the methods and all... UGH! If you have seen something somewhere and remember well enough to recall the link I'd be grateful. It won't be used so much for code as it will be a basis for conversation with 2 other developers and an executive team on a large project that is all but devoid of error handling.
Jeff Richter's book CLR via C# has an excellent chapter devoted to Exception management for the runtime and C#. It goes into great depth for the following topics: - Preferring try / finally blocks for managing exceptions (instead of blindly catching everything that comes your way) - Setting Exception policy handlers for the main thread and worker threads These two strategies allow you centrally manage unhandled exceptions for all threads while still allowing you to have precise control over the exceptions that you chose to handle. I use his strategies as a consultant/contractor for all my .Net projects. It's amazing the responses you get from dev's when you explain to them they should use try / finally liberally and not try / catch !!! Like Richter's work for native code, his runtime work goes into great detail and is very helpful.
-
Or you could just use the Language of the Gods: VB6. It has a construct
On Error Resume Nextthat does the same thing all that complicated fugly looking See Pound stuff does for only a single line per file.Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots. -- Robert Royall
-
Shog9 wrote:
.NET code throws exceptions
Some .NET code catches and hides exceptions. I was once debugging into .NET source, and I did something with a ComboBox (WinForms). I get getting a funny error, on an operation I normally often perform on ComboBoxes. It turns out that .NET basically does an empty catch in that operation, but because of my deeper debugging, it was breaking when thrown, deep inside the innocent looking combo.
In the MS Validation Application Block you get the message "A validation method threw an exception" when your custom validation method throws one. You can't disable this swallowing. So you have to step through all your validation methods line by line to find the line that suddenly ends your debugging view. (As I write this, I realize that I could install the source code for the VAB and then hope that I would find the current validation method name in some variable.)
modified on Wednesday, February 11, 2009 2:32 PM