aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes B&S: Which Exceptions to be shown to user? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "B&S: Which Exceptions to be shown to user?" Watch "B&S: Which Exceptions to be shown to user?" New topic
Author

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

Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855
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 ]

    SCJP, SCJD, SCWCD, SCBCD
    Frans Janssen
    Ranch Hand

    Joined: Dec 29, 2004
    Posts: 357
    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.


    SCJP 1.4, SCJD
    Reza Rahman
    author
    Ranch Hand

    Joined: Feb 01, 2005
    Posts: 580
        
        5
    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?


    Independent Consultant — Author, EJB 3 in Action — Expert Group Member, Java EE 6 and EJB 3.1
    Darya Akbari
    Ranch Hand

    Joined: Aug 21, 2004
    Posts: 1855
    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

    Joined: Dec 29, 2004
    Posts: 357
    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

    Joined: Aug 21, 2004
    Posts: 1855
    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

    Joined: Dec 29, 2004
    Posts: 357
    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

    Joined: Aug 21, 2004
    Posts: 1855
    No logging at all . Thanks for your comments.

    Regards,
    Darya
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: B&S: Which Exceptions to be shown to user?