• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

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

 
Darya Akbari
Ranch Hand
Posts: 1855
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
     
    Frans Janssen
    Ranch Hand
    Posts: 357
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.
     
    Reza Rahman
    author
    Ranch Hand
    Posts: 580
    5
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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?
     
    Darya Akbari
    Ranch Hand
    Posts: 1855
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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 Janssen
    Ranch Hand
    Posts: 357
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.
     
    Darya Akbari
    Ranch Hand
    Posts: 1855
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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?
     
    Frans Janssen
    Ranch Hand
    Posts: 357
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.
     
    Darya Akbari
    Ranch Hand
    Posts: 1855
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    No logging at all . Thanks for your comments.

    Regards,
    Darya
     
    With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic