[jdom-interest] XMLOutputter to the rescue (get/setText)

[Steven D. Keens]

The problem with setText() is that it always succeeds, at least its current
implementation. And it seems that many people want it to stay that way. I
agree with you about it being dangerous.  Anything that has unexpected side
effects, is unintuitive, or is improperly named is just waiting for a
catastrophe.  The severity of that catastrophe is all relative.

I mentioned in an earlier email today that we can prevent the unexpected
just by renaming the method to something like removeAllContentAndSetText().
No ambiguity, no exceptions, just one long named method!  It's easier to
type than a try catch block while maintaining the convenience of setText()
and being very explicit. Put it in perspective: Your finger tips grow back,
but your wallet doesn't grow money.

Also, getText() is ambiguous in whether it's recursive or not.  Thus, it is
equaly dangerous.

If we want to use JDOM in a mission critical environment then we should be
worrying about preventing the unexpected and ambiguous at all costs.  This
doesn't necessarily mean JDOM will be harder to use but the convenience
methods have to be properly named.


--
Steven Keens                mailto:skeens at planetfred.com
Planetfred Inc.             http://www.planetfred.com
44 Byward Market, Suite 240, Ottawa, ON, K1N 7A2, Canada

The most exciting phrase in science, the one which heralds
new discoveries, is not "Eureka!", but "That's funny!"
                       -- Isaac Asimov


>-----Original Message-----
>From: jdom-interest-admin at jdom.org
>[mailto:jdom-interest-admin at jdom.org]On Behalf Of Elliotte Rusty Harold
>Sent: Thursday, July 12, 2001 09:25
>To: 'JDOM Interest List'
>Subject: Re: [jdom-interest] XMLOutputter to the rescue (get/setText)
>
>
>At 5:37 PM -0700 7/11/01, guru at stinky.com wrote:
>
>
>>>  The current behavior is simply not an option, even with a Javadoc
>>> note on the point. It's just way too dangerous.
>>
>>It's dangerous because...?  I agree it's a little unintuitive, but not
>>dangerous.  (Not as dangerous as an unchecked exception, for instance,
>>which could unexpectedly kill a thread without warning.)
>>
>
>The current behavior is dangerous because I might write code, test
>it, see that it's working, put it into production and have it run
>correctly for two weeks at which points somebody throws a document
>that's formed in a slightly different way at it and it processes
>it incorrectly. Consequently a trade doesn't get executed that
>should be, or vice versa, or it gets executed at the wrong price.
>A laser scalpel cuts along the wrong coordinates. A nuclear
>reactor fails to shut down. Most cases would be less catastrophic
>than this, but you get the idea.
>
>If I have designed my code to miss handling an important case,
>then it should immediately notify someone that it's entered an
>unexpected state that it cannot properly handle. I would prefer to
>make this particular exception a checked exception so that
>programmers would be forced to consider the possibility of mixed
>content and how they'll handle it if it arrives. But regardless of
>whether the exception is checked or unchecked, silent failure is
>not an option. The method either succeeds or it tells somebody
>that it failed.
>--
>
>+-----------------------+------------------------+-------------------+
>| Elliotte Rusty Harold | elharo at metalab.unc.edu | Writer/Programmer |
>+-----------------------+------------------------+-------------------+
>|          The XML Bible, 2nd Edition (Hungry Minds, 2001)           |
>|              http://www.ibiblio.org/xml/books/bible2/              |
>|   http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/   |
>+----------------------------------+---------------------------------+
>|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
>|  Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/     |
>+----------------------------------+---------------------------------+
>_______________________________________________
>To control your jdom-interest membership:
>http://lists.denveronline.net/mailman/options/jdom-interest/youradd
r at yourhost.com