Hey there, I keep hearing over and over again that I should ALWAYS use custom exceptions in my web apps.. The problem is that I dont see any reason for making custom exceptions when they all are handled in the global.asax(write to database etc.) anyway.. So why should I use them?
+2
A:
I almost never use custom exceptions. When I do manually throw an exception I provide a detailed message.
I've found the maintenance of the exceptions is not worth the hassle.
Update
Lets put this into context. The Question is if someone should create custom exceptions in a web application. I envision this as a basic crud app.
Web Applications
In Web Applications you almost NEVER need custom exceptions. Data is being written to the database and data is being read from the database. The data is then consumed by some sort of UI: MVC, WPF, WebForms... etc. In such an app, there is not a opportunity for custom exceptions. Every application is different, so there will be exceptions to this...
Frameworks
Frameworks are an entirely different animal. As a framework developer it's your job to provide visibility into why an error has occurred. I expect verbose exceptions from a framework, maybe custom, maybe not. I expect enough information to solve the error.
As @Wyatt Barnett pointed out a new exception should offer something more, something that can not be done with an existing class.
Reason I Would Create a Custom Exception
- To convey more detailed and specific information about the error.
- To provide a means to catch this error conditions (i.e. 'FileNotFoundExeception', this allows a business decision to be made at a higher layer.)
Chuck Conway
2010-09-06 19:05:05
Maintenance? Articulate plz
JohnIdol
2010-09-06 19:18:45
@JohnIdol There is no benefit to creating custom exceptions in a web application. In most cases the exceptions are dumped into some logging framework attached to the OnError event in HttpAppication.
Chuck Conway
2010-09-06 21:21:23
I do not agree that there are no benefits but that's not what I was asking though. I do not see your point in terms of maintenance, once you create the custom exception what kind of maintenance does it require?
JohnIdol
2010-09-07 16:48:29
@JohnIdol Create them if you think they will work for you. I've created them, thinking that I was following "best practices." They got in the way. There was no additional value -- !oO! I have an exception with a special name, big deal. In the end I removed all the custom classes and replaced them with 'Exception' with verbose descriptions. It was just more classes to maintain. Even if they are just sitting there. I still had to look at them.
Chuck Conway
2010-09-08 03:41:54
A:
Having proper exceptions class for a given exception or problem is very important for the code that will use the class you are writing.
Example, the WriteLine method of TextWriter can throw the following exceptions:
ArgumentNullException
ObjectDisposedException
IOException
FormatException
Imagine your code if that method would throw only Exception.
Pierre 303
2010-09-06 19:09:43
Well, given the OP's description, I would imagine he would do nothing different at all, and would *still* let the global exception handler handle it. Typed exceptions are only useful if you plan to *catch* them for control-flow reasons. Some people elect to never do this for various reasons.
Kirk Woll
2010-09-06 19:12:10
Lets say we have 2 classes that can throw FormatException - Should there be 2 diffrent try/catch blocks then? - Dont see any reason for custom exceptions.. only if I plan on specific error page for the exception.
ebb
2010-09-06 19:13:06
Kirk comment is valid. You must do it when you think it will provide value to the class consumers. For exemmple, a class that parse a file will obviously need its own ParsingException object. Regarding your question user407674, when a method can throw multiple exceptions, just add a catch block for each, and keep one try and finally. Here is an example: http://functionx.com/csharp1/examples/multiexceptions.htm
Pierre 303
2010-09-06 19:18:29
To be catched as a parsing exception in the first place. I also add a member that contains the line that caused the problem for further handling.
Pierre 303
2010-09-06 19:32:09
No. Are you confused? Read this article:http://blog.gurock.com/articles/creating-custom-exceptions-in-dotnet/. If you still don't understand, that probably mean you don't need them. Yet.
Pierre 303
2010-09-06 19:49:08
+3
A:
I think the line for where it becomes a good idea for making your own custom exceptions rather than just using standard sorts of exceptions with descriptive errors comes somewhere at the point where you need to add more data to the exception. EG, just imagine you had an import routine and rather than just throwing an InvalidOperationException when you get mangled data, you could throw an ImporterException and include in said exception the row number and raw data of the import?
Wyatt Barnett
2010-09-06 19:14:25
Ah, so for simple things like checking for user tampering and throw an exception if true should just be a normal ArgumentException since no extra parameters needed?
ebb
2010-09-06 19:46:50
A:
Let's break down the use of exceptions:
We throw an exception when our routine encounters this situation:
"I cannot continue"
We throw a specific BCL exception when our routine encounters this situation:
"I cannot continue and one of the more specific BCL exception types describes the precise reason why (i.e. FileNotFoundException)"
We throw a custom exception type when our routine encounters this situation:
"I cannot continue because of a reason which none of the BCL exceptions can accurately describe to interested parties"
Rex M
2010-09-07 02:16:21