Exception as a data container?

[Yupp Cook]

Hi all!

Is it a good Exception handling practice to add extra data to an Exception? The data is used and needed only if the Exception occurs. Or is it an "abuse" of the Exception as a data container?

Here's the szenario where I need it:
Booking consists of:

lock record
read record
update record
unlock record

Reading is needed to check if the record which is about to be booked hasn't changed meanwhile the client did some searching and finally fired the booking event. If there's a change booking fails and a DataChangedException is thrown back to the client. The DataChangedException wraps the actual record read info which then easily can be shown without starting another reading process.

Thanx
Yupp

[Dan Burke]

I actually used this approach. I added an additonal constructor to my booking exception class which took the customer id as a parameter. I used the parameter on the gui to give more info to the user.

i thought about this for a bit..but i eventually felt that it wasnt doing an harm to extend the functionality of an exception subclass..but only as long as the added functionality is relative to the exception itself and by nature, very minimal.

I'm interested in what others think about this too.

[Yupp Cook]

Hello ranchers!
No more comments on this? Come on, spend 5 minutes!
Yupp

[Ed Tse]

Can you please elborate on how it benefits by storing the object? From what I understand from your question, you are just trying to display the record info, why can't you just pass in the message when you throw the exception:
throw new DataChangedException(" This record " + record.displayInfo());

I might have misunderstood something but I just don't find the need to store objects in an exception and neither should it.

[Yupp Cook]

The client tries to book a record. Therefor it has to execute an update. If the record hasn't changed by a different client, it updates, booking succeeds, no Exception. But if the record has changed, it throws the DataChangedException, updating/booking fails and the client has to display the actualized record which can be easily wraped by the DataChangedException.

[Ed Tse]

When the client caught the exception, he can re-get the record with the same record number.

The exception should not anticipate what the catcher will do next, I don't think that's part of an exception's role.

[Yupp Cook]

Thanx Ed.
I guess you are right. I'll rethink and change it.
Yupp

[Aruneesh Salhotra]

It is a good idea to report the error in two hold manner.
User level error information, alongwith the admin level information.

I read it in one of the threads, and started implementing this while displaying the error information.