exception handling best practice?

Question

When is it appropriate to add exception values to the Exception dictionary?   When is it appropriate to make a custom exception class with custom property values (instead of using a more generic exception class and adding values to the Exception dictionary?

Ex:

ApplicationException ae = new ApplicationException("User not authorized.")

ae.Data.Add("UserId", 1234);

ae.Data.Add("ResourceId", 56789);

throw ae;

vs

AuthorizationException ae = new AuthorizationException("User not authorized.";

ae.UserId = 1234;

ae.ResourceId = 56789;

throw ae;

thanks!

Answer 1

When you need easy access to the values, I'd create a custom exception.

I've never had to add information to Data ever, go with your second option.  It's cleaner.

---

Coding Light - Illuminated Ideas and Algorithms in Software
Coding Light Wiki • LinkedIn • ForumsBrowser

Answer 2

David,

Can we use Enterprise Library 4.1 Exception Application block here:

http://msdn.microsoft.com/en-us/library/dd203116.aspx

Regards,
Jai

Answer 3

Hello

The second approach has the additional benefit when you catch and handle the exception. It allows you to only catch what you can handle.

            try
            {
                AuthorizationException ae = new AuthorizationException();
                ae.UserId = 1234;
                ae.ResourceId = 56789;
                throw ae;
            }
            catch (AuthorizationException authExp)
            {
                // Handle the AuthorizationException exception
            }

So I prefer the second one too.

---

Regards,
Jialiang Ge
MSDN Subscriber Support in Forum
If you have any feedback of our support, please contact [e-mail].
Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.

Answer 4

Unless you don't have a *very* good reason to use the Data property (for storing and retrieving supplementary information, or for building logic upon key conflicts), I simply wouldn't use Exception.Data at all. Besides, remember that there is no guarantee on the security of the key/value pairs, so if you need to store security relevant information this would be the wrong place to do. Also key names of your Data property might conflict with other key names which results in sometimes very hard to catch program errors. There were reports that suggested that you also might run into serialization problems in WCF (http://social.msdn.microsoft.com/forums/en-US/wcf/thread/d1ae669f-9a62-4628-86c1-c15ff4068843/) while using non-primitive data types in Exception.Data.

BUT if you *know* what you do, Exception.Data can be of great help, allowing you to add real value to your application with very little effort.

Answer 5

It does seem convenient to add your custom data to the Exception without having to create your own exception class.

I think it would be useful in cases where you need to add a small piece of information to the class but not really worth enough to create our own class. Plus we can add our own custom objects to the Data dictionary.

---

Ganesh Ranganathan
[Please mark the post as answer if it answers your question]
blog.ganeshzone.net

Answer 6

Hello Scott

Many community friends have shared their insights in this thread. Could you please check them out. If you have any other questions, please feel free to post here.

---

Regards,
Jialiang Ge
MSDN Subscriber Support in Forum
If you have any feedback of our support, please contact [e-mail].
Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.