classpath-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [cp-patches]: Patch: JPasswordField


From: Roman Kennke
Subject: Re: [cp-patches]: Patch: JPasswordField
Date: Thu, 25 Aug 2005 10:36:48 +0200

Hi,

> > > Are you sure you want to return the empty string if there is a
> > > BadLocationException thrown from the underlying code? It looks like that
> > > might hide problems with the Document (sub) class implementation. Better
> > > would be to chain it in a InternalError() and throw that since it seems
> > > that BadLocationException should never be thrown when getText() is
> > > called like this.
> > 
> > I handled this the same way JTextComponent does.
> > 
> >     try
> >       {
> >     return doc.getText(0, doc.getLength());
> >       }
> >     catch (BadLocationException e)
> >       {
> >     // This should never happen.
> >     return "";
> >       }
> >   }
> > 
> > I think it makes most sense to return an empty string. 
> 
> To be honest I think that if something should never happen then we
> should throw an InternalError (with the original exception as cause).
> Returning something in that case just hides a real problem.

I always throw an AssertionError in such cases, with a message 'This and
that should never happen here'. It may not matter much if it's an
InternalError or an AssertionError, but the semantics of an
AssertionError are closer to the problem than an InternalError (which
indicates an unexpected condition in the Java VM itself).

Generally, at all places where we have comments like 'At this point we
should have this state of fields' or 'This exception should never be
thrown here' I would consider it wiser to insert an assert() statement
or throw an AssertionError. This way the real problem can be discovered
more quickly.

/Roman








reply via email to

[Prev in Thread] Current Thread [Next in Thread]