Bugzilla – Full Text Bug Listing
|Summary:||Spec should clarify that reader/write close() get called after exceptions|
Description ScottKurz 2014-01-31 16:07:19 UTC
Comment 1 ScottKurz 2014-02-05 15:19:38 UTC
Added 'future' to whiteboard to consider idea of extending Closeable in a future release.
Comment 2 ScottKurz 2014-02-13 13:12:33 UTC
Not committing to address in future, just listing as candidates and pointing out they're excluded from current Maintenance Rel.
Comment 3 ScottKurz 2014-10-07 10:49:31 UTC
As I'm looking back on this now I'm realizing that I got too hung up on the idea that it was too late to start implementing Closeable (with idempotent close()). We could have still considered saying this was the required behavior even without the interface to enforce this further. For what it's worth, I'm almost positive the RI may call close() twice in some cases, for example if the writer close() throws an exception on certain paths we might retry to close both reader and writer. Noticing this in walking through my fix for Bug 6259.
Comment 4 ScottKurz 2016-06-20 20:47:36 UTC
Another thing to clarify: the diagrams in Section 11, showing reader and writer close() in a single transaction, could lead to some confusion. E.g. if the writer close() throws an exception, and the tran rolls back, what does this mean for the reader? Do we still call reader close()? In what transaction? This should be clarified. Note that there are now several close()-related issues open (e.g. Bug 6456, Bug 7684) and it might make sense to tackle them together instead of via the current breakdown.