[jdom-interest] detach() [eg]
edward.kenworthy at exchange.co.uk
Thu Apr 26 02:10:02 PDT 2001
Firstly I can find zero, no, none, nada documentation that would suggest ISE
is limited to the case ERH mentions. Without a root the Document *is* in an
illegal state, no amount of arguing is going to change that. ISE is the way
to flag it.
Secondly, changing the behaviour of detach() in the way Elliotte has
suggested, whilst ideal if we were starting from scratch, will break
existing code and would cause considerable confusion. Modifying the Document
to throw an ISE maintains all existing code.
Thirdly, Document isn't a bean so I fail to see why it should be constrained
to behave like one.
Personally I think the evidence is overwhelming that throwing an ISE is the
best, easiest, most intuitive and correct thing to do.
From: Joseph Bowbeer [mailto:jozart at csi.com]
Sent: 26 April 2001 09:31
To: jdom-interest at jdom.org
Subject: [jdom-interest] detach() [eg]
> I suspect IllegalStateException was intended for situations
> where thread issues could leave an object in an illegal state;
> e.g. a thread finished half an update before it was interrupted.
I agree with Elliotte that adding ISE to Document is an uncomfortable
Having a "getter" method throw an ISE is not very bean-like. Users expect
"getter" methods to work without exception or side-effects. Introspection
is based on this contract.
While there are some "getters" that throw ISE, such as getWriter() and
getOutputStream() in the servlet API, these methods are producing a value,
not simply fetching a property. These "getters" have no associated
"setters", and they are understood to be active methods, with documented
side-effects. (With URL connections, even the order in which the getters
are called is important.)
None of the description above applies documents. The way I see it, the root
is a property of the document, and a property has a value, or is null.
By the way, have we seen real code samples where an ISE would actually help?
A code snippet or two might shed some light on this.
I agree with Patrick that the "root" of the problem is that Element.detach
can operate implicitly on the Document's rootElement property. If we
prevent elt.detach() from operating on a root element, then we prevent the
dangerous side-effects. As long as we provide an explicit way for the
programmer to remove/replace the rootElement of the Document, then it
probably matters less to us that the Document's rootElement might be null --
because the programmer did it explicitly.
To control your jdom-interest membership:
More information about the jdom-interest