Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #35394 > unrolled thread

What happens when format gets a wrong argument

Back to article view | Back to comp.lang.java.programmer

Contents

  What happens when format gets a wrong argument Cecil Westerhof <Cecil@decebal.nl> - 2016-08-18 23:01 +0200
    Re: What happens when format gets a wrong argument Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-08-18 17:31 -0400
      Re: What happens when format gets a wrong argument Arne Vajhøj <arne@vajhoej.dk> - 2016-08-18 19:21 -0400
        Re: What happens when format gets a wrong argument Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-08-19 08:22 -0400
          Re: What happens when format gets a wrong argument Gene Wirchenko <genew@telus.net> - 2016-08-19 10:40 -0700
          Re: What happens when format gets a wrong argument Arne Vajhøj <arne@vajhoej.dk> - 2016-08-19 20:19 -0400
    Re: What happens when format gets a wrong argument Cecil Westerhof <Cecil@decebal.nl> - 2016-08-19 01:25 +0200
    Re: What happens when format gets a wrong argument Arne Vajhøj <arne@vajhoej.dk> - 2016-08-18 19:31 -0400
    Re: What happens when format gets a wrong argument Arne Vajhøj <arne@vajhoej.dk> - 2016-08-18 19:35 -0400
      Re: What happens when format gets a wrong argument Cecil Westerhof <Cecil@decebal.nl> - 2016-08-19 07:23 +0200

#35394 — What happens when format gets a wrong argument

I had a function in ScheduledExecutorService where I changed a
parameter for format from long to double, but I forgot to change the
format string. The result was that the function gets an unchecked
IllegalFormatConversionException and silently terminated on the format
statement. Is this normal? And where do I find a good description
about this?
Is there a way to get things automatically logged?

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [next] | [standalone]

#35395

On 8/18/2016 5:01 PM, Cecil Westerhof wrote:
> I had a function in ScheduledExecutorService where I changed a
> parameter for format from long to double, but I forgot to change the
> format string. The result was that the function gets an unchecked
> IllegalFormatConversionException and silently terminated on the format
> statement. Is this normal? And where do I find a good description
> about this?

     It's normal.  Java's printf-inspired format strings are not quite
as good as C's, because C compilers (by and large) are able to sanity-
check the formats at compile time while JavaC doesn't (yet, anyhow).

     For a description, see the JavaDoc for java.util.Formatter, which
says (near the top) "[...] Java formatting is more strict than C's; for
example, if a conversion is incompatible with a flag, an exception will
be thrown."  (It also says "In C inapplicable flags are silently
ignored," which is wrong -- but inability to comprehend C is to be
expected from Java folks, who can't even grok "unsigned.")

> Is there a way to get things automatically logged?

     Don't make misteaks?  :(

-- 
esosman@comcast-dot-net.invalid
The Tooth Fairy has gone high-tech, now pays in Bitecoin.

[toc] | [prev] | [next] | [standalone]

#35400

On 8/18/2016 5:31 PM, Eric Sosman wrote:
> On 8/18/2016 5:01 PM, Cecil Westerhof wrote:
>> I had a function in ScheduledExecutorService where I changed a
>> parameter for format from long to double, but I forgot to change the
>> format string. The result was that the function gets an unchecked
>> IllegalFormatConversionException and silently terminated on the format
>> statement. Is this normal? And where do I find a good description
>> about this?
>
>     It's normal.  Java's printf-inspired format strings are not quite
> as good as C's, because C compilers (by and large) are able to sanity-
> check the formats at compile time while JavaC doesn't (yet, anyhow).

The C way is extremely practical/useful.

But it is a bit mixing compiler and library responsibility. It
must be a hardcoded special case in the compiler.

Arne

[toc] | [prev] | [next] | [standalone]

#35407

On 8/18/2016 7:21 PM, Arne Vajhøj wrote:
> On 8/18/2016 5:31 PM, Eric Sosman wrote:
>> On 8/18/2016 5:01 PM, Cecil Westerhof wrote:
>>> I had a function in ScheduledExecutorService where I changed a
>>> parameter for format from long to double, but I forgot to change the
>>> format string. The result was that the function gets an unchecked
>>> IllegalFormatConversionException and silently terminated on the format
>>> statement. Is this normal? And where do I find a good description
>>> about this?
>>
>>     It's normal.  Java's printf-inspired format strings are not quite
>> as good as C's, because C compilers (by and large) are able to sanity-
>> check the formats at compile time while JavaC doesn't (yet, anyhow).
>
> The C way is extremely practical/useful.
>
> But it is a bit mixing compiler and library responsibility. It
> must be a hardcoded special case in the compiler.

     Yes.  I don't see why javac could not have similar special
cases, but it doesn't.  (They'd be subject to similar limitations,
too, but I think even an imperfect job would be better than none.)

     As for "mixing responsibility" -- well, there's already plenty
of precedent in Java for the language to have "special knowledge" of
the class library.  The compiler rejects `throw "error";', thus
revealing special knowledge of `Throwable'.  The compiler knows
about `StringBuilder', and relies upon it for "language" features.
The compiler knows enough about the class library to do automatic
generation of `Integer.valueOf(n)' and `theDouble.doubleValue()'
and the like.  It does not seem to me that adding knowledge of
`Formatter' would amount to a violation of purity -- there would be
practical difficulties, yes, but no loss of innocence.

-- 
esosman@comcast-dot-net.invalid
The Tooth Fairy has gone high-tech, now pays in Bitecoin.

[toc] | [prev] | [next] | [standalone]

#35416

On Fri, 19 Aug 2016 08:22:12 -0400, Eric Sosman
<esosman@comcast-dot-net.invalid> wrote:

[snip]

>     Yes.  I don't see why javac could not have similar special
>cases, but it doesn't.  (They'd be subject to similar limitations,
>too, but I think even an imperfect job would be better than none.)

     Yup.

>     As for "mixing responsibility" -- well, there's already plenty
>of precedent in Java for the language to have "special knowledge" of
>the class library.  The compiler rejects `throw "error";', thus
>revealing special knowledge of `Throwable'.  The compiler knows
>about `StringBuilder', and relies upon it for "language" features.
>The compiler knows enough about the class library to do automatic
>generation of `Integer.valueOf(n)' and `theDouble.doubleValue()'
>and the like.  It does not seem to me that adding knowledge of
>`Formatter' would amount to a violation of purity -- there would be
>practical difficulties, yes, but no loss of innocence.

     Violation of purity?  Ha!

     The type of purity that I am concerned with first is whether my
programs are correct.  And, in general, the sooner I find out, the
better.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#35421

On 8/19/2016 8:22 AM, Eric Sosman wrote:
> On 8/18/2016 7:21 PM, Arne Vajhøj wrote:
>> On 8/18/2016 5:31 PM, Eric Sosman wrote:
>>> On 8/18/2016 5:01 PM, Cecil Westerhof wrote:
>>>> I had a function in ScheduledExecutorService where I changed a
>>>> parameter for format from long to double, but I forgot to change the
>>>> format string. The result was that the function gets an unchecked
>>>> IllegalFormatConversionException and silently terminated on the format
>>>> statement. Is this normal? And where do I find a good description
>>>> about this?
>>>
>>>     It's normal.  Java's printf-inspired format strings are not quite
>>> as good as C's, because C compilers (by and large) are able to sanity-
>>> check the formats at compile time while JavaC doesn't (yet, anyhow).
>>
>> The C way is extremely practical/useful.
>>
>> But it is a bit mixing compiler and library responsibility. It
>> must be a hardcoded special case in the compiler.
>
>     Yes.  I don't see why javac could not have similar special
> cases, but it doesn't.  (They'd be subject to similar limitations,
> too, but I think even an imperfect job would be better than none.)
>
>     As for "mixing responsibility" -- well, there's already plenty
> of precedent in Java for the language to have "special knowledge" of
> the class library.  The compiler rejects `throw "error";', thus
> revealing special knowledge of `Throwable'.  The compiler knows
> about `StringBuilder', and relies upon it for "language" features.
> The compiler knows enough about the class library to do automatic
> generation of `Integer.valueOf(n)' and `theDouble.doubleValue()'
> and the like.  It does not seem to me that adding knowledge of
> `Formatter' would amount to a violation of purity -- there would be
> practical difficulties, yes, but no loss of innocence.

Using certain library functions in the generated code is not as
dirty as checking the content of a string constant.

But it would be OK for me. I am just trying to explain
why it may not have been so obvious to implement.

Arne

[toc] | [prev] | [next] | [standalone]

#35401

On Thursday 18 Aug 2016 23:48 CEST, Stefan Ram wrote:

>> Is there a way to get things automatically logged?
>
> When »java.exe« is used under Windows and the process is
> terminated by an uncaught exception, this is usually 
> reported to the console, but the report can also be
> redirected to a file.

Because the function is run in a ScheduledExecutorService the process
is not terminated and there is no report either. That makes this type
of error hard to find.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#35402

On 8/18/2016 5:01 PM, Cecil Westerhof wrote:
> I had a function in ScheduledExecutorService where I changed a
> parameter for format from long to double, but I forgot to change the
> format string. The result was that the function gets an unchecked
> IllegalFormatConversionException and silently terminated on the format
> statement. Is this normal? And where do I find a good description
> about this?

As already explained by others then this is documented behavior.

And many people would consider it an advantage that this is type safe.

But if if you don't want that type safety then look at
MessageFormat.format!

Arne

[toc] | [prev] | [next] | [standalone]

#35403

On 8/18/2016 5:01 PM, Cecil Westerhof wrote:
> Is there a way to get things automatically logged?

You can always catch and log explicit in the executing
code.

:-)

Arne

[toc] | [prev] | [next] | [standalone]

#35406

On Friday 19 Aug 2016 01:35 CEST, Arne Vajhøj wrote:

> On 8/18/2016 5:01 PM, Cecil Westerhof wrote:
>> Is there a way to get things automatically logged?
>
> You can always catch and log explicit in the executing
> code.

That is what I now do:
    ses.scheduleAtFixedRate(new Runnable() {
            @Override
            public void run() {
                try {
                    saveMemoryLine();
                } catch (Exception e) {
                    logMessage(e.getMessage());
                }
            }
        }, 1, 1, TimeUnit.MINUTES);

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web