Forums Register Login

Ken Krebs question - are you out there?

+Pie Number of slices to send: Send
Ken,
2 Questions:
1st.In your infamous design 389/400 post, you mention under locking the following:


It is vital that any exception that occurs during processing is caught and rethrown after the Contractor has been unlocked.


Does this mean that update, book...are responsible for calling unlock
before it throws an exception or catches an exception.
For example, in you update method you may have something like:

2nd Did you do any special processing for SecurityException such as
shutting down their current session?
+Pie Number of slices to send: Send
Bill,
"infamous", eh , I'm flattered.

Does this mean that update, book...are responsible for calling unlock before it throws an exception or catches an exception.


My approach is similar to what Phillipe suggested in the related NX: Unlock before throw Exception thread.
In my ServicesImpl book method, which can throw RecordNotFoundException or IOException, I lock the Contractor record and then invoke my Data update method in a try block to perform the booking. If an exception is thrown during the Data update invocation, I catch it and then rethrow it after unlocking the Contractor in the finally block.

Did you do any special processing for SecurityException such as
shutting down their current session?


I did not as it is not specifically thrown anywhere in my application.
I will post a little bit more about your first question in the related thread.
+Pie Number of slices to send: Send
Ken,
Are you unlocking, catching, and then rethrowing in your ServicesImpl
or directly from the method - for example book.
so it basically looks like
lock
try {
book
} catch...
) catch...
}finally {
unlock
}
+Pie Number of slices to send: Send
Bill,
Actually, it's conceptually more like this, in the ServicesImpl.book method which can throw RecordNotFoundException:
+Pie Number of slices to send: Send
Ken,
I didn't really notice a difference. Do you just use one general catch
that catches Exception instead catching each one.
Thanks bill
+Pie Number of slices to send: Send
Just a quick comment on Ken's code snippet from above:

I don't think you would even need the catch statement above. You can have just a try-finally, which I believe would accomplish the same thing.
TJ
+Pie Number of slices to send: Send
Good point, Terry.
+Pie Number of slices to send: Send
Terry,
With the code as shown, the catch block isn't needed as you pointed out. In my real code, I use it to catch my DataAccessException and then extract the real nested IOException from it for rethrowing.
+Pie Number of slices to send: Send
Thanks Ken. I'm sure I speak for all of us when I say we appreciate that you are still out here helping even after you have passed.
TJ
+Pie Number of slices to send: Send
Bill,

Do you just use one general catch
that catches Exception instead catching each one.


I have only one catch block for DataAccessException whose only purpose is to extract the nested IOException for rethrowing. As TJ pointed out, it isn't necessary for RecordNotFoundException or some other exception (runtime) that I simply want to percolate unmodified up the calling hierarchy.
BTW, the book method declares that it can throw IOException as well as RecordNotFoundException.
It's kind of neat they way it works as there is no need for any hideous nested try-catch-finally blocks.
Those cherries would go best on cherry cheesecake. Don't put those cherries on this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com


reply
reply
This thread has been viewed 1119 times.
Similar Threads
B&S - Contractor
NX: Data a singleton and no cache - trouble? Andrew help if you can
RecordNotFoundException in locking
NX: Notes on a design that passed 389/400
To synchronize or not to synchronize?
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 29, 2024 00:34:08.