When to Define a Custom Exception
-
Yes but there are times when it is advantageousness to differentiate between a custom exception
try
{
Foo();
}
catch(UserIsMoronException ex)
{
BeatSensless();
}
catch(Exception ex)
{
Log();
}
I know the language. I've read a book. - _Madmatt
Mark Nischalke wrote:
catch(UserIsMoronException ex)
They REALLY need to add this one to the framework. :)
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997 -
Mark Nischalke wrote:
catch(UserIsMoronException ex)
They REALLY need to add this one to the framework. :)
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997John Simmons / outlaw programmer wrote:
Mark Nischalke wrote: catch(UserIsMoronException ex) They REALLY need to add this one to the framework.
They did, and 85% of the exceptions where caught by, ... you guessed it right... ;P
Yusuf May I help you?
-
Hi, I would like to get a few expert opinions on the question of when to define a custom exception. According to some books I have read, the exceptions built into .NET should generally be reserved for .NET's own use and developers should create custom exceptions for classes they create. This seems to me to be unnecessary - and even undesirable - at times. For example, if I had a class with a function that had a single integer parameter that should always be in the range 0-9 and it receives 42, I would have thought the best exception to throw would be the predefined System.ArgumentOutOfRangeException; it seems to fit the bill perfectly. If you were creating a whole code library, I can see the value of defining a custom set of exceptions for the library, but for individual lumps of code, it seems like overkill. I would be very interested to hear other opinions on this subject or get links to good articles on this subject. Best wishes, Patrick
Depends on the situation. Mostly one should use built in exceptions, but for some reason the exception is too generic or does not fit in your scenario, then creating a custom exception is better.
-
If you have NegativeDepositAmmountException inherit ArgumentOutOfRangeException you can have the best of both worlds. You can encode as much semantic information as you need, while simultaneously making it easy for a consumer to handle common error cases without having to learn all the details of your implementation up front.
3x12=36 2x12=24 1x12=12 0x12=18
It's a very nice idea, but not always practical, and could lead to some inconsistencies. I learned the hard way to take a lot of care when deriving a class, and follow more rigidly LSP (Liskov Substitution Principle). In the same example, EmptyAdressException cannot be derived from NullReferenceException, in the same way a Square cannot be derived from a Rectangle.
I see dead pixels Yes, even I am blogging now!
-
It's a very nice idea, but not always practical, and could lead to some inconsistencies. I learned the hard way to take a lot of care when deriving a class, and follow more rigidly LSP (Liskov Substitution Principle). In the same example, EmptyAdressException cannot be derived from NullReferenceException, in the same way a Square cannot be derived from a Rectangle.
I see dead pixels Yes, even I am blogging now!
I'm not following. If I understand LSP correctly it says that if I derive Square from Rectangle that Squares must have all the properties of a rectangle; which they do so the derivation should be allowed under LSP. What am I missing?
3x12=36 2x12=24 1x12=12 0x12=18
-
I'm not following. If I understand LSP correctly it says that if I derive Square from Rectangle that Squares must have all the properties of a rectangle; which they do so the derivation should be allowed under LSP. What am I missing?
3x12=36 2x12=24 1x12=12 0x12=18
That's what I thought at first, too. But LSP is not about properties, nor methods. LSP is about "substitution", and that is more closely related to an specialization. A Red Rectangle can be derived from a Rectangle, but a Square is much more an abstract class on its own. The "is a" relationship of OO is flawed; you can read more about that on this pdf[^]
I see dead pixels Yes, even I am blogging now!
-
Hi, I would like to get a few expert opinions on the question of when to define a custom exception. According to some books I have read, the exceptions built into .NET should generally be reserved for .NET's own use and developers should create custom exceptions for classes they create. This seems to me to be unnecessary - and even undesirable - at times. For example, if I had a class with a function that had a single integer parameter that should always be in the range 0-9 and it receives 42, I would have thought the best exception to throw would be the predefined System.ArgumentOutOfRangeException; it seems to fit the bill perfectly. If you were creating a whole code library, I can see the value of defining a custom set of exceptions for the library, but for individual lumps of code, it seems like overkill. I would be very interested to hear other opinions on this subject or get links to good articles on this subject. Best wishes, Patrick
My decision is to define a custom exception when the need to do so is... well... exceptional :) Really though… If you have an exception definition that clearly fits an existing model then use it, why reinvent the wheel at all? If you are creating a new failure state, usually most likely based upon things like a domain specific business rule, then you define a new exception of your own design. BUT you have to keep in mind that quite often even doing this can cause issues because as we all know business rules change. This means that you may want to be slightly less specific and more generalized by defining a business rule exception and allowing it to express the rule broken, and the why it was considered broken enough to trigger the exception. I would like to know what books you say are specifically stating that new exceptions should always be defined instead of using the Dotnet ones. I would have to have a conversation with that author :) I am not even sure I see the value in writing all custom exceptions when creating a whole new code library of your new library is something that sits on top of the Dotnet framework. If you are writing something that is completely disconnected at all form the Dotnet stuff then yeah, you have to create your own exceptions to throw, but that makes no sense in this context really since your question was more related to being told to not use Dotnet exceptions :). If you did want to keep all the exceptions specific to your application layer then there is nothing from stopping you from writing all your own custom exception code, but I would still recommend that you consider catching the Dotnet specific stuff and then just re throwing your own as a general application side exception and then include the Dotnet exception in that object. Seems a bit messy but I guess it is doable and will not require too much writing on your part. Just remember that every additional line of code you have to write can possibly introduce a new error (and thus CAUSE an exception :) ) so I like to keep them down to a minimum. One other argument I would make for maintaining the existing exceptions provided by the framework is that anytime they change you need to ensure that your code changes also. This means that if you have wrapped all of the Dotnet exceptions in your code, any time the framework changes you have to review all those changes to see what effects they have on your code. Not that you may not have to do the same if the base libraries change their exceptions and you have to catch th
-
Hi, I would like to get a few expert opinions on the question of when to define a custom exception. According to some books I have read, the exceptions built into .NET should generally be reserved for .NET's own use and developers should create custom exceptions for classes they create. This seems to me to be unnecessary - and even undesirable - at times. For example, if I had a class with a function that had a single integer parameter that should always be in the range 0-9 and it receives 42, I would have thought the best exception to throw would be the predefined System.ArgumentOutOfRangeException; it seems to fit the bill perfectly. If you were creating a whole code library, I can see the value of defining a custom set of exceptions for the library, but for individual lumps of code, it seems like overkill. I would be very interested to hear other opinions on this subject or get links to good articles on this subject. Best wishes, Patrick
I think you would do this when you want to specify additional information beyond a string message describing what went wrong. Some exceptions take advantage of their name to provide additional information, like NullReferenceException. If one is thrown, clearly something is null and the code didn't expect it to be. SqlException contains additional properties related to line numbers in stored procedures that failed, for example. So, if you'd like to provide additional properties to describe what went wrong, create a class that inherits Exception that has those properties.
-
I generally just do this instead of creating custom exception objects:
catch (Exception ex)
{
throw new Exception("My custom exception message", ex);
}".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997Having a type-safe object has some advantages over a string. It's harder to filter if you're examining a string, and I like having a class that describes the problem and being able to catch and handle that specific case. Or worse- let the user decide whether or not those kind of exceptions need be logged (like file-access errors for the sysadmin, common networkexceptions for the networkadmin, and whether the user allows the app to send unhandled exceptions with a stacktrace back home) There's a string in the custom exception of course, along with placeholders for values to help diagnose the problem. But in code, I can act on the object itself, and I don't need to depend on the formatting of a string. It's a matter of preference, I guess, as you can accomplish the same visual and functional endresult. No, the worst kind of exceptions are translated ones. Yes, I know about the unlocalize website, but that's not exactly convenient. I'm hoping that I can rectify some by removing the .NET language packs from my PC.
I are Troll :suss:
-
It's a very nice idea, but not always practical, and could lead to some inconsistencies. I learned the hard way to take a lot of care when deriving a class, and follow more rigidly LSP (Liskov Substitution Principle). In the same example, EmptyAdressException cannot be derived from NullReferenceException, in the same way a Square cannot be derived from a Rectangle.
I see dead pixels Yes, even I am blogging now!
-
Hi, I would like to get a few expert opinions on the question of when to define a custom exception. According to some books I have read, the exceptions built into .NET should generally be reserved for .NET's own use and developers should create custom exceptions for classes they create. This seems to me to be unnecessary - and even undesirable - at times. For example, if I had a class with a function that had a single integer parameter that should always be in the range 0-9 and it receives 42, I would have thought the best exception to throw would be the predefined System.ArgumentOutOfRangeException; it seems to fit the bill perfectly. If you were creating a whole code library, I can see the value of defining a custom set of exceptions for the library, but for individual lumps of code, it seems like overkill. I would be very interested to hear other opinions on this subject or get links to good articles on this subject. Best wishes, Patrick
I'll typically only write custom exceptions in the Model (Business) layer. The reason for doing this is so the presentation layer can consume the exception and display a message which is non-technical and meaningful to the user. Probably breaches best practices but it works well example: Model receives an OutOfRangeException, Model creates a MyModelException with the message "The number of passengers must be greater than 0" and throws the exception to the presentation layer.
Architecture is extensible, code is minimal.
-
Hi, I would like to get a few expert opinions on the question of when to define a custom exception. According to some books I have read, the exceptions built into .NET should generally be reserved for .NET's own use and developers should create custom exceptions for classes they create. This seems to me to be unnecessary - and even undesirable - at times. For example, if I had a class with a function that had a single integer parameter that should always be in the range 0-9 and it receives 42, I would have thought the best exception to throw would be the predefined System.ArgumentOutOfRangeException; it seems to fit the bill perfectly. If you were creating a whole code library, I can see the value of defining a custom set of exceptions for the library, but for individual lumps of code, it seems like overkill. I would be very interested to hear other opinions on this subject or get links to good articles on this subject. Best wishes, Patrick
Wow! What a response. Thanks to everyone. Some very good advice in there, and lots to think about. I'm glad I asked; that was really helpful. Best wishes, Patrick
-
Hi, I would like to get a few expert opinions on the question of when to define a custom exception. According to some books I have read, the exceptions built into .NET should generally be reserved for .NET's own use and developers should create custom exceptions for classes they create. This seems to me to be unnecessary - and even undesirable - at times. For example, if I had a class with a function that had a single integer parameter that should always be in the range 0-9 and it receives 42, I would have thought the best exception to throw would be the predefined System.ArgumentOutOfRangeException; it seems to fit the bill perfectly. If you were creating a whole code library, I can see the value of defining a custom set of exceptions for the library, but for individual lumps of code, it seems like overkill. I would be very interested to hear other opinions on this subject or get links to good articles on this subject. Best wishes, Patrick
Patrick Skelton wrote:
According to some books I have read, the exceptions built into .NET should generally be reserved for .NET's own use
If that was the case, why the hell are those classes public? I have never read anything like that. You should be creating custom exceptions only when your code interacts with something external. For instance, a service should return custom exceptions back to client in order to hide the complete information of the actual exception. Not because you are ashamed of it but it doesn't makes sense client knowing details of services. Same logic I use in case anything wrong happens in database. Apart from my data layer code, none of the layers get the complete trace of the error. Apart from all the custom exceptions, I also keep one catch block taking in Exception as a type (in the outermost code layer) just in case we get an exception which I have not handled properly.
"Your code will never work, Luc's always will.", Richard MacCutchan[^]
-
Wow! What a response. Thanks to everyone. Some very good advice in there, and lots to think about. I'm glad I asked; that was really helpful. Best wishes, Patrick
Patrick. There are some questions which it is a joy to answer, and this is definitely one of them. Good question.
I'm not a stalker, I just know things. Oh by the way, you're out of milk.
Forgive your enemies - it messes with their heads
-
I generally just do this instead of creating custom exception objects:
catch (Exception ex)
{
throw new Exception("My custom exception message", ex);
}".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997John Simmons / outlaw programmer wrote:
I generally just do this instead of creating custom exception objects: catch (Exception ex) { throw new Exception("My custom exception message", ex); }
I believe that is a mistake. I discuss this on my article[^], more deeply but there are 3 main problems with this approach: 1. Internationalization: when you need to catch your exception you'll need to have some sort of switch on the text message. With i18n, which message should you use on the switch? 2. You'll force your users to catch (Exception ex), which is a too broad class and they'll need to handle a lot of other different exceptions. 3. You'l force your users to stop using the more efficient catch (XXXXException) and use a switch instead, which is both less readable and less efficient.
I see dead pixels Yes, even I am blogging now!
-
Hi, I would like to get a few expert opinions on the question of when to define a custom exception. According to some books I have read, the exceptions built into .NET should generally be reserved for .NET's own use and developers should create custom exceptions for classes they create. This seems to me to be unnecessary - and even undesirable - at times. For example, if I had a class with a function that had a single integer parameter that should always be in the range 0-9 and it receives 42, I would have thought the best exception to throw would be the predefined System.ArgumentOutOfRangeException; it seems to fit the bill perfectly. If you were creating a whole code library, I can see the value of defining a custom set of exceptions for the library, but for individual lumps of code, it seems like overkill. I would be very interested to hear other opinions on this subject or get links to good articles on this subject. Best wishes, Patrick
In my opinion there are two situations which REQUIRE the creation of your own exception class. 1. You have a business or data layer checking errors from data entry and throwing an exception. Example: Customer name is missing. By having an exception class specific to your application, the user interface can then create custom error messages attach them to the appropriate user control and display them in a user friendly way that is specific to your application. This also allows for easy implementation of internationalization (localization) by allowing you to create a module that will pick the language specific error message for each individual situation. You don't really want to do that kind of localization at the lower levels. 2. You are implementing a service that crosses machine boundaries. In that case, you want an exception class that serializes well and provides the necessary detail to both debug any situation and to provide sufficiently detailed error messages that will be useful to the end user. Personally, I am still trying to get used to the idea that throwing exceptions is an appropriate coding practice at an application level. I come from an assembly language and UNIX background where "exceptions" were machine-level faults that totally destroy the application code context, so it was something you would never do in application code. But in the .Net world, throwing exceptions is just as appropriate for handling application errors as returning an error code would be in the UNIX world. Robert Tanenbaum
-
In my opinion there are two situations which REQUIRE the creation of your own exception class. 1. You have a business or data layer checking errors from data entry and throwing an exception. Example: Customer name is missing. By having an exception class specific to your application, the user interface can then create custom error messages attach them to the appropriate user control and display them in a user friendly way that is specific to your application. This also allows for easy implementation of internationalization (localization) by allowing you to create a module that will pick the language specific error message for each individual situation. You don't really want to do that kind of localization at the lower levels. 2. You are implementing a service that crosses machine boundaries. In that case, you want an exception class that serializes well and provides the necessary detail to both debug any situation and to provide sufficiently detailed error messages that will be useful to the end user. Personally, I am still trying to get used to the idea that throwing exceptions is an appropriate coding practice at an application level. I come from an assembly language and UNIX background where "exceptions" were machine-level faults that totally destroy the application code context, so it was something you would never do in application code. But in the .Net world, throwing exceptions is just as appropriate for handling application errors as returning an error code would be in the UNIX world. Robert Tanenbaum
Hi, Robert, Thanks for that. I know what you mean about exceptions. I too cut my teeth on assembly language, and even when I started venturing into C/C++ (in video games), exceptions were to be avoided wherever possible. In fact, one game I worked on shipped with a release exception handler that simply did while( 1 );. Best wishes, Patrick