• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Locking is interrupted

 
Oliver Rensen
Ranch Hand
Posts: 109
Eclipse IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello all,

AFAIK every locking-method should contain the following code-excerpt:



What is the best way to deal with the catch-clause? IMO there are three possibilities:

  • 1. Ignore the InterruptedException.
  • 2. Create a new subclass from RuntimeException and throw it.
  • 3. Include a return-statement.


  • 1. A bad solution, because a java-idiom says that we should never swallow an exception, thus we must handle it. BTW, when a thread gets an InterruptedException, it's not wise to continue.
    2. The client will catch the RuntimeException and display the containing error-message (e.g. "The booking was interrupted"). But in this case the client will get a second error-message from my unlock-method, because unlock throws a SecurityException, when a specific lock cannot be unlocked.
    3. The lock-method returns before it can lock the record, but the unlock-method will throw a SecurityException too, because my unlock-call is part of the finally-clause. BTW, Mark Spritzler wrote there should only be ONE return-statement in a method.

    IMO all three proposals are not a good design.

    How has other SCJDs handled this problem?

    Regards

    Oliver
     
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander
    Pie
    Posts: 12007
    215
    C++ Firefox Browser IntelliJ IDE Java Mac Oracle
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Oliver,

    My personal preference would be to go with option 2 - throw an exception. If your code has been interrupted then it is an exception to normal processing logic, and should be handled as such - you cannot just ignore it (ruling out option 1). And one of the reasons for having exceptions is so that we don't have to create "magic" return codes to indicate error conditions and have large amounts of code to validate that calls to methods worked (ruling out option 3).

    However it appears that you may have incorrect logic at your book() method, which is causing you these dilemmas in your Data class. Reading between the lines, it appears that you have code in your book() method similar to:



    But the logic is not valid - if lock() threw an exception, then it is not valid to try and call unlock(). This is especially true since you are throwing a RuntimeException in your lock() method.

    If you move the call to lock() method outside of the try ... finally block, then you can correctly handle the RuntimeException.

    Regards, Andrew
     
    Oliver Rensen
    Ranch Hand
    Posts: 109
    Eclipse IDE Firefox Browser Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Andrew,

    thank you for your opinion and the clarification about my try/catch/locking-failure. With your correction it should be work perfectly!

    Regards,

    Oliver
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic