B&S: Which Exceptions to be shown to user?

Hi all,

in my assignment I have these methods using the following three Exceptions:

RecordNotFoundException: lock, unlock, read, update, delete

SecurityException: unlock, update, delete

DuplicateKeyException: create

Now, which of above Exceptions make sense to be shown to a user

Regards,
Darya
[ May 27, 2005: Message edited by: Darya Akbari ]

Originally posted by Darya Akbari:
my assignment I have these methods using the following three Exceptions:

RecordNotFoundException: lock, unlock, read, update, delete
SecurityException: unlock, update, delete
DuplicateKeyException: create

Now, which of above Exceptions make sense to be shown to a user

Hi Darya,

If you don't make any bugs in your client code, SecurityException and DuplicateKeyException should never occur. The first because it will only occur if you try to abuse the database and the second because you won't be creating new records from your client. So there is no need to present these to the user.

RecordNotFoundException might occur if a client has deleted a record that another client wants to view or book. In that case it seems reasonable to me to give the user feedback that the record is no longer available.

Frans.

As far as I can see, there is no reason not to bubble up all exceptions to the user, however remote they might possibly be. You would do the same thing if you were to treat any part of the database/server code as third party components, right?

Hi Frans and Reza (where are you from Reza

?),

Thanks for your response. Frans you told me once I should also implement the delete and create methods of the assignment's data interface.

Doesn't that mean that we should also care about the DuplicateKeyException in the case of create? Actually I did implement both methods up to the GUI because I was not sure where to leave the implementation. As a side effect I can test my implementation.

In general I can think of all these exceptions as meaningful exceptions and hence like Reza's exceptions bubble up

to the user.

Regards,
Darya

Frans you told me once I should also implement the delete and create methods of the assignment's data interface.

Doesn't that mean that we should also care about the DuplicateKeyException in the case of create? Actually I did implement both methods up to the GUI because I was not sure where to leave the implementation. As a side effect I can test my implementation.

In general I can think of all these exceptions as meaningful exceptions and hence like Reza's exceptions bubble up to the user.

OK, if you did implement these functions also in the user interface, I agree with you and Reza that the DuplicateKeyException can be meaningful and should be presented.

I still don't see however how you would ever get a SecurityException, except in the case of a bug.

Frans.

Hi Frans,

you are right about the SecurityException (SE). That one should never happen since all the SE throwing methods (unlock, delete, update) are called in atomic methods like bookContractor where the lock cookie obtained in previous steps and again used in the SE throwing methods.

And since the very last data methods are all synchronized no other thread can step in between and throw the SecurityException.

So, tell me what shall I do with the SE? Shall I do a printStackTrace() at db layer level?

So, tell me what shall I do with the SE? Shall I do a printStackTrace() at db layer level?

That sounds OK to me. I guess you did not implement any logging mechanism for your server? Otherwise that would be a nice place to write the exception to.
But printing to System.err will be fine in this situation too.

Frans.

No logging at all

. Thanks for your comments.

Regards,
Darya