.NET Framework Bookmark and Share   
 index > .NET Base Class Library > Do not throw System.Exception
 

Do not throw System.Exception

In the help for "throwing exceptions" > "standard types", it says "Do not throw System.Exception or System.SystemException.". What is the reasoning behind this, and what is it expected that you should throw instead?

For example, normally I might want code similar to the following in much of my error handling logic after doing any error logging and cleanup so the calling logic can do whatever it needs to do in case of error:

throw new System.Exception("Error from MyObject.Whatever()");

or in the middle of a function if something goes wrong I'll want to raise an error with an explanation and jump to the error handler for that function:

throw new System.Exception("Unexpected Spanish Inquisition");

But, the documentation would appear to indicate that I should be doing something else.

sriesch
The reason is it's too hard for the "catcher" of the exception to identify what's really going on. Raw Exceptions can basically only be parsed by a human user. An IOException, for example, can at least be identified as an I/O error. Someone who anticipates them can use catch(IOException x) to handle that one specifically.

You're encouraged to inherit from System.Exception to create your own exception types if none of the standard ones seem appropriate. So, you'd have an UnexpectedSpanishInquisitionException, for example Smile

-Ryan / Kardax
Ryan Lamansky
The reason is it's too hard for the "catcher" of the exception to identify what's really going on. Raw Exceptions can basically only be parsed by a human user. An IOException, for example, can at least be identified as an I/O error. Someone who anticipates them can use catch(IOException x) to handle that one specifically.

You're encouraged to inherit from System.Exception to create your own exception types if none of the standard ones seem appropriate. So, you'd have an UnexpectedSpanishInquisitionException, for example Smile

-Ryan / Kardax
Ryan Lamansky

Sothere isn'tany actual problem with a System.Exception being used, it is simply that this exception cannot be distinguished from any other System.Exception, right? I am thinking ofa case where thelogic catching the exception doesn't care in any way what the exception is and simply needs to know if there was/wasn't an exception becuaseall exceptions wouldbe handled in exactly the same way (abort whatever was being done, tell the user it was not completed correctly.).

sriesch
In that case, if any exception would result in the operation being aborted, then you would simply use a "catch(Exception)" thing. All exceptions, regardless of type, would be caught.

The guidelines regarding throwing and catching the base Exception type are mainly targetted toward class library development; there's not much benefit in end-user applications. I would still at least throw exceptions of my own design, just as a good habit Smile

-Ryan / Kardax
Ryan Lamansky

Ok, thanks!

sriesch

You can use google to search for other answers

Custom Search

More Threads

• Converting dataset to bytes arrray
• Accessing / Mapping a Linux formatted drive from Windows
• Key messages in WndProc when form is minimized?
• windows service
• Deployment Issue
• Append to file. Maximum performance
• CurrentCulture and CurrentUICulture "lost" on the creation of a new thread
• Performance output help... using the managementClass(Win32_PerfFormattedData_PerfProc_Process)
• Urgent: MSI forms Memory Leak: Major Issue
• ArrayList in C#.net