I have an aversion to finalizers because the JVM resurrection contract
is so hard you can hit JVM bugs
(a finalizer happens pre-mortem and can resurrect the object)
I tend to put such notifications postmortem using reference queues of
weak references
These can be hairy too though. The hardest part of the contract is that
you have to maintain a strong ref to the weak ref ... and also because
it is postmortem you no longer have the problem object.
I also tend to optionally create strack traces on object creation which
then get given in the error message ... otherwise it is not much help to
know you made a mistake ... where was it?
Jeremy
On 8/28/2012 8:53 AM, Paul Gearon wrote:
On Sat, Aug 25, 2012 at 6:24 AM, Andy Seaborne <[email protected]> wrote:
On 24/08/12 19:50, Jeremy Carroll wrote:
On 8/24/2012 10:59 AM, Stephen Allen wrote:
execAsk(), execConstruct(), and execDescribe() do (or if they don't
currently, they should) close the QueryExecution before they return.
In this case you calling close() is redundant, but can't hurt.
-Stephen
I think this is the most unobvious case from the documentation.
In my view, either it should be documented that close() is called by the
implementation of these methods (and then it should be called from
within a finally block), or the current documentation on close() should
strongly advise the use of a finally block and articulate that it is
necessary even in the surprising cases.
Jeremy
The documentation shows the query execution object being closed each time.
http://jena.apache.org/documentation/query/app_api.html
An approach that I've found works is to check to see if the object is
closed in a finalizer. If not, then this indicates that the user is
not using the API correctly, and a message to this effect can be
logged. This can also be a good opportunity to call close() in those
cases where the object has acquired resources that should be freed,
but won't be after a standard GC.
Extending on this, if verbose logging is enabled, the constructor can
save a stack trace (a lá Throwable) and this can be displayed when an
unclosed object is reported, thereby showing exactly where the
unclosed object was allocated.
But this is just a suggestion. :-)
Regards,
Paul
