I've been searching for an error handling comprehensive...

code frog 0

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.

Nish Nishant

There's a fairly decent article[^] here on CP you might want to take a look at.

Regards, Nish

Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
My latest book : C++/CLI in Action / Amazon.com link

Shog9 0

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 code throws an exception then some more code won't run. And as we've already established, some code is pretty much guaranteed to throw an exception sooner or later. What if some more code is 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!

Dan Neely

Or you could just use the Language of the Gods: VB6. It has a construct On Error Resume Next that 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

Brady Kelly

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.

led mike

Now you have a problem with kittens?! :omg: You really need to get away from web development for a while. :laugh:

Shog9 wrote:

What if some more code is crucial to your Business Process?

Exactly. Like you still need to soak those low income people for a high rate mortgage even though the qualification function throws an exception so you know they won't be able to pay back the loan. :-\ So you need:

try{
privatizedProfits();

}catch(WeAreBrokeException weBrokeEx)
{
socializedLosses();
}

code frog 0

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

code frog 0

I should have expected such a response from you. So uh... go out and Google for me and get me a deeper answer with deeper meanings that will bring peace to the world and new hope to man.

Shog9 0

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/throw to 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.

Todd Smith

It's still considered a holy war topic.

Todd Smith

Lost User

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')

code frog 0

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:

Clickok

Formidable! I feel good about navigate 3 pages in the lounge to find and to read this! :-D

For God so loved the world, that he gave his only begotten Son, that whosoever believeth in him should not perish, but have everlasting life.(John 3:16) :badger:

Hamed Musavi

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 MessageBoxes or 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

Adriaan Davel

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

dmitri_sps

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 Musavi

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

BillWoodruff

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

cl0306_

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")]

Gary Wheeler

try
{
// some code
// some more code
// even more code
// a veritable shitload of more code
}
catch (SpewCoffeeOnMonitorException exception)
{
Priceless();
}

Software Zen: delete this;