There are three public fields in java.lang.Float that I don't know what they
do exactly. Their names are WIDEFP_SIGNIFICAND_BITS, WIDEFP_MIN_EXPONENT,
and WIDEFP_MAX_EXPONENT. There doesn't appear to be any explanation in the
1.2 JavaDocs either (they aren't even listed). Could someone who know
"John Keiser" <[EMAIL PROTECTED]> writes:
> Finally, in both Float and Double, the toString() method needs a little
> elaboration. It would be nice to know what format the resulting String will
> be in. Will it be in exponential notation? Will it ever be in regular
> notation, and under what c
> Sent: Monday, February 08, 1999 11:54 AM
> To: John Keiser
> Cc: Classpath
> Subject: Re: java.lang.Float fields
>
>
> "John Keiser" <[EMAIL PROTECTED]> writes:
>
> > Finally, in both Float and Double, the toString() method needs a little
> &g
lto:[EMAIL PROTECTED]]On Behalf Of
> > Brian Jones
> > Sent: Monday, February 08, 1999 11:54 AM
> > To: John Keiser
> > Cc: Classpath
> > Subject: Re: java.lang.Float fields
> >
> >
> > "John Keiser" <[EMAIL PROTECTED]> writes:
&g
One more thing I need from the Float/Double person[s]: where (and how)
can spaces be in the input string, and what happens when an unrecognized
character is hit? Is a NumberFormatException thrown, or is the rest of the
string simply ignored? (I have wondered this myself.) Actually this goe
"John Keiser" <[EMAIL PROTECTED]> writes:
> One more thing I need from the Float/Double person[s]: where
> (and how) can spaces be in the input string, and what happens when
> an unrecognized character is hit? Is a NumberFormatException
> thrown, or is the rest of the string simply ignored?
> From: Paul Fisher
>
> "John Keiser" <[EMAIL PROTECTED]> writes:
>
> > And I'm still missing documentation for those WIDEFP_* fields in
> > Float.
>
> They're explained in the strictfp documentation.
>
Aha! I went searching the bowels of the change docs and found out why I
couldn't find those f
"John Keiser" <[EMAIL PROTECTED]> writes:
> Also, I have a question about Float and Number, specifically the
> methods byteValue() and shortValue(). They are implemented in
> Number, calling intValue() and casting down. Is there a reason for
> this?
Yes. byteValue() and shortValue() were adde
Paul Fisher <[EMAIL PROTECTED]> writes:
> "John Keiser" <[EMAIL PROTECTED]> writes:
>
> > Also, I have a question about Float and Number, specifically the
> > methods byteValue() and shortValue(). They are implemented in
> > Number, calling intValue() and casting down. Is there a reason for
>
> From: Brian Jones
>
> Paul Fisher <[EMAIL PROTECTED]> writes:
>
> > "John Keiser" <[EMAIL PROTECTED]> writes:
> >
> > > Also, I have a question about Float and Number, specifically the
> > > methods byteValue() and shortValue(). They are implemented in
> > > Number, calling intValue() and casti
> One more thing I need from the Float/Double person[s]: where (and how)
>can spaces be in the input string, and what happens when an unrecognized
>character is hit? Is a NumberFormatException thrown, or is the rest of the
>string simply ignored? (I have wondered this myself.) Actually this
"Aaron M. Renn" <[EMAIL PROTECTED]> writes:
> If you put them in the method decl, then the compiler will force any
> callers to catch them or declare that they throw the method instead
> of allowing them to propagate upward silently as normal.
This is not the case. All RuntimeExceptions declare
> From: Aaron M. Renn [mailto:[EMAIL PROTECTED]]
>
> >I declared an @exception clause, but I removed the throws
> >NullPointerException part from all of them.
>
> I recommend against declaring that a method throws exceptions from
> java.lang. (Javadoc'ing them is probably good though, but perhaps
"John Keiser" <[EMAIL PROTECTED]> writes:
> I agree completely. The decision is completely out of our hands,
> though; we need to throw exactly the same exceptions as Java 2, so
> that stuff compiled against us will work as expected on Sun, and
> vice versa.
This is not the case. See section 8
"Aaron M. Renn" wrote:
>
> I recommend against declaring that a method throws exceptions from
> java.lang. (Javadoc'ing them is probably good though, but perhaps things
> like NullPointerException are a bit overkill). If you put them in the
> method decl, then the compiler will force any caller
> If you put them in the
> method decl, then the compiler will force any callers to catch them or
> declare that they throw the method instead of allowing them to propagate
> upward silently as normal.
Is this also true for RuntimeExceptions? I could be mistaken, but from what
Paul was saying it
>> If you put them in the method decl, then the compiler will force any
>> callers to catch them or declare that they throw the method instead
>> of allowing them to propagate upward silently as normal.
>
>This is not the case. All RuntimeExceptions declared in the throws
>clause are ignored.
Hm
Brian Jones wrote:
>
> Paul Fisher <[EMAIL PROTECTED]> writes:
>
> > Please change your commenting style to conform to GNU standards. The
> > double stars on each line are terribly ugly.
>
> single '*' for everything but the first part of the comment if it is
> to be included in javadoc (as in
> From: [EMAIL PROTECTED]
>
> "John Keiser" <[EMAIL PROTECTED]> writes:
>
> > I agree completely. The decision is completely out of our hands,
> > though; we need to throw exactly the same exceptions as Java 2, so
> > that stuff compiled against us will work as expected on Sun, and
> > vice versa
19 matches
Mail list logo
