I've been searching for an error handling comprehensive...
-
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