I've been searching for an error handling comprehensive...
-
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.
Are you talking exception handling or error handling - surely two separate topics (unless you choose to throw exceptions when a validation error is detected, for example, in which case you should think of all the kittens)
___________________________________________ .\\axxx (That's an 'M')
-
Yeah, i was being kinda tongue-in-cheek there; truth is, i tend to disagree to at least some extent with most recommendations on exception and error handling... My own precepts are as follows:
- An unhandled exception is entirely appropriate in instances where you lack the ability to write an effective recovery mechanism. Provide a mechanism for reporting and recording such errors, so that you can identify and fix the underlying problem.
- Throw only exceptions you have a well-defined strategy in place for catching (use finally rather than
catch/throwto perform cleanup). - Use custom exceptions carefully.
- Catch only exceptions you know how to deal with ("deal with" may involve simply attaching context and re-
throwing - see #2). An exception you can't entirely recover from should be allowed to bring down the program (see #1) cleanly (see #2 -finally/using).
You might find the Exception Handling Application Block[^] interesting... IMHO, it's severely programmer-unfriendly and over-engineered, but you could still learn something from the general strategy.
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:
-
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!
-
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.
I tried a lot of ways. What I found best so far, for object oriented languages that support exceptions, was this: 1. Every class that wants to report an error shall throw exception. It shall handle all exceptions from underneath layers or calls inside the class and throw it's own exception(s) to upper layer. This is because many exceptions don't have a good meaning to upper layers so we wrap them inside our own exceptions. 2. Create a singleton class who is responsible for handling all errors at the topmost layer(presentation). Every exception thrown to this layer shall be controlled by this singleton class. It might use a message box to show the message or use a logger class to log errors. But the point is that it displays all errors with the same UI which makes users happy and we don't see all those
MessageBoxesor error related codes everywhere inside different classes or layers. 3.I, have never done before but, also thought about having a design pattern like composite to transfer all exceptions, layer to layer each with packing the underlying exception inside exceptions that it throws, to the upper class/layer so even if our singleton central handler shows a friendly message it can log underlying errors that might be useful for later debugging or support after release by iterating through attached exceptions to the exception it received. Maybe not the best way of doing it but up until now I found it to be the most clean possible solution. I would appreciate if anyone has any better solution. :)"In the end it's a little boy expressing himself." Yanni
-
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.
I did an article here on CP with a non-technical approach (for Part 1 in anycase), more of a business approach to when things go bad... http://www.codeproject.com/KB/exception/ExceptionConcepts.aspx[^]
____________________________________________________________ Be brave little warrior, be VERY brave
-
I tried a lot of ways. What I found best so far, for object oriented languages that support exceptions, was this: 1. Every class that wants to report an error shall throw exception. It shall handle all exceptions from underneath layers or calls inside the class and throw it's own exception(s) to upper layer. This is because many exceptions don't have a good meaning to upper layers so we wrap them inside our own exceptions. 2. Create a singleton class who is responsible for handling all errors at the topmost layer(presentation). Every exception thrown to this layer shall be controlled by this singleton class. It might use a message box to show the message or use a logger class to log errors. But the point is that it displays all errors with the same UI which makes users happy and we don't see all those
MessageBoxesor error related codes everywhere inside different classes or layers. 3.I, have never done before but, also thought about having a design pattern like composite to transfer all exceptions, layer to layer each with packing the underlying exception inside exceptions that it throws, to the upper class/layer so even if our singleton central handler shows a friendly message it can log underlying errors that might be useful for later debugging or support after release by iterating through attached exceptions to the exception it received. Maybe not the best way of doing it but up until now I found it to be the most clean possible solution. I would appreciate if anyone has any better solution. :)"In the end it's a little boy expressing himself." Yanni
Hamed Mosavi wrote:
for object oriented languages that support exceptions
I'm wondering, are you talking about C# only, or about Java too? The presence of "throws" clause in the language changes all such discussions quite considerably: simply speaking, exceptions stop being a problem - and become your friend ;P
-
Hamed Mosavi wrote:
for object oriented languages that support exceptions
I'm wondering, are you talking about C# only, or about Java too? The presence of "throws" clause in the language changes all such discussions quite considerably: simply speaking, exceptions stop being a problem - and become your friend ;P
dmitri_sps wrote:
exceptions stop being a problem - and become your friend
:-D
dmitri_sps wrote:
are you talking about C# only, or about Java too?
No. I haven't done any java coding yet. I mostly worked in c++ and c#. Right now I'm doing this in a C# application and it works good.
"In the end it's a little boy expressing himself." Yanni
-
Yeah, i was being kinda tongue-in-cheek there; truth is, i tend to disagree to at least some extent with most recommendations on exception and error handling... My own precepts are as follows:
- An unhandled exception is entirely appropriate in instances where you lack the ability to write an effective recovery mechanism. Provide a mechanism for reporting and recording such errors, so that you can identify and fix the underlying problem.
- Throw only exceptions you have a well-defined strategy in place for catching (use finally rather than
catch/throwto perform cleanup). - Use custom exceptions carefully.
- Catch only exceptions you know how to deal with ("deal with" may involve simply attaching context and re-
throwing - see #2). An exception you can't entirely recover from should be allowed to bring down the program (see #1) cleanly (see #2 -finally/using).
You might find the Exception Handling Application Block[^] interesting... IMHO, it's severely programmer-unfriendly and over-engineered, but you could still learn something from the general strategy.
Hi Shog9, May we look forward to a CP article on error handling from you ? best, Bill
"Many : not conversant with mathematical studies, imagine that because it [the Analytical Engine] is to give results in numerical notation, its processes must consequently be arithmetical, numerical, rather than algebraical and analytical. This is an error. The engine can arrange and combine numerical quantities as if they were letters or any other general symbols; and it fact it might bring out its results in algebraical notation, were provisions made accordingly." Ada, Countess Lovelace, 1844
-
I did an article here on CP with a non-technical approach (for Part 1 in anycase), more of a business approach to when things go bad... http://www.codeproject.com/KB/exception/ExceptionConcepts.aspx[^]
____________________________________________________________ Be brave little warrior, be VERY brave
there's no shortage of advice on MSDN: [http://msdn.microsoft.com/en-us/library/seyhszts(VS.80).aspx - .NET Framework Developer's Guide, Best Practices for Handling Exceptions http://msdn.microsoft.com/en-us/library/5b2yeyab(VS.80).aspx - .NET Framework Developer's Guide, Handling and Throwing Exceptions http://msdn.microsoft.com/en-us/library/ms229014(VS.80).aspx - .NET Framework Developer's Guide, Design Guidelines for Exceptions](http://msdn.microsoft.com/en-us/library/seyhszts\(VS.80\).aspx - .NET Framework Developer's Guide, Best Practices for Handling Exceptions<br mode=) [[^](http://msdn.microsoft.com/en-us/library/seyhszts\(VS.80\).aspx - .NET Framework Developer's Guide, Best Practices for Handling Exceptions<br mode= "New Window")]
-
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!
try
{
// some code
// some more code
// even more code
// a veritable shitload of more code
}
catch (SpewCoffeeOnMonitorException exception)
{
Priceless();
}Software Zen:
delete this; -
Are you talking exception handling or error handling - surely two separate topics (unless you choose to throw exceptions when a validation error is detected, for example, in which case you should think of all the kittens)
___________________________________________ .\\axxx (That's an 'M')
Isn't that the following case:
throw _Kittens;
Software Zen:
delete this; -
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: