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

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

Unexpected Boxing Error at Runtime

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

Contents

  Unexpected Boxing Error at Runtime j4n bur53 <janburse@fastmail.fm> - 2018-01-04 15:16 +0100
    Re: Unexpected Boxing Error at Runtime Eric Douglas <e.d.programmer@gmail.com> - 2018-01-04 07:04 -0800
    Re: Unexpected Boxing Error at Runtime Eric Sosman <esosman@comcast-dot-net.invalid> - 2018-01-04 10:13 -0500
    Re: Unexpected Boxing Error at Runtime Eric Douglas <e.d.programmer@gmail.com> - 2018-01-04 08:01 -0800
      Re: Unexpected Boxing Error at Runtime Marcel Mueller <news.5.maazl@spamgourmet.org> - 2018-01-04 18:33 +0100
        Re: Unexpected Boxing Error at Runtime Kiwi User <martin@mydomain.invalid> - 2018-01-04 19:29 +0000
      Re: Unexpected Boxing Error at Runtime Eric Sosman <esosman@comcast-dot-net.invalid> - 2018-01-04 15:09 -0500
        Re: Unexpected Boxing Error at Runtime Daniele Futtorovic <da.futt.news@laposte.net> - 2018-01-04 21:43 +0100
          Re: Unexpected Boxing Error at Runtime Arne Vajhøj <arne@vajhoej.dk> - 2018-01-04 15:53 -0500
            Re: Unexpected Boxing Error at Runtime Daniele Futtorovic <da.futt.news@laposte.net> - 2018-01-05 16:06 +0100
              Re: Unexpected Boxing Error at Runtime Gene Wirchenko <genew@telus.net> - 2018-01-05 09:51 -0800
                Re: Unexpected Boxing Error at Runtime Daniele Futtorovic <da.futt.news@laposte.net> - 2018-01-05 20:59 +0100
                  Re: Unexpected Boxing Error at Runtime Eric Douglas <e.d.programmer@gmail.com> - 2018-01-05 12:15 -0800
                    Re: Unexpected Boxing Error at Runtime Kiwi User <martin@mydomain.invalid> - 2018-01-05 21:52 +0000
                      Re: Unexpected Boxing Error at Runtime Gene Wirchenko <genew@telus.net> - 2018-01-08 11:13 -0800
                  Re: Unexpected Boxing Error at Runtime Eric Sosman <esosman@comcast-dot-net.invalid> - 2018-01-05 16:27 -0500
                    Re: Unexpected Boxing Error at Runtime Daniele Futtorovic <da.futt.news@laposte.net> - 2018-01-06 00:06 +0100
                      Re: Unexpected Boxing Error at Runtime Kiwi User <martin@mydomain.invalid> - 2018-01-05 23:57 +0000
                  Re: Unexpected Boxing Error at Runtime Arne Vajhøj <arne@vajhoej.dk> - 2018-01-07 20:06 -0500
                    Re: Unexpected Boxing Error at Runtime bursejan@gmail.com - 2018-01-08 04:10 -0800
                      Re: Unexpected Boxing Error at Runtime bursejan@gmail.com - 2018-01-08 04:31 -0800
                      Re: Unexpected Boxing Error at Runtime Daniele Futtorovic <da.futt.news@laposte.net> - 2018-01-08 16:25 +0100
                        Re: Unexpected Boxing Error at Runtime Arne Vajhøj <arne@vajhoej.dk> - 2018-01-08 20:05 -0500
                          Re: Unexpected Boxing Error at Runtime bursejan@gmail.com - 2018-01-08 17:55 -0800
                  Re: Unexpected Boxing Error at Runtime Gene Wirchenko <genew@telus.net> - 2018-01-08 11:19 -0800
                    Re: Unexpected Boxing Error at Runtime Daniele Futtorovic <da.futt.news@laposte.net> - 2018-01-08 20:40 +0100
                      Re: Unexpected Boxing Error at Runtime Gene Wirchenko <genew@telus.net> - 2018-01-08 18:03 -0800
                        Re: Unexpected Boxing Error at Runtime Daniele Futtorovic <da.futt.news@laposte.net> - 2018-01-16 02:33 +0100
                          Re: Unexpected Boxing Error at Runtime bursejan@gmail.com - 2018-01-22 14:26 -0800
                            Re: Unexpected Boxing Error at Runtime bursejan@gmail.com - 2018-01-22 14:33 -0800
          Re: Unexpected Boxing Error at Runtime Arne Vajhøj <arne@vajhoej.dk> - 2018-01-04 19:16 -0500
            Re: Unexpected Boxing Error at Runtime Kiwi User <martin@mydomain.invalid> - 2018-01-05 12:17 +0000
    Re: Unexpected Boxing Error at Runtime j4n bur53 <janburse@fastmail.fm> - 2018-01-05 00:13 +0100
      Re: Unexpected Boxing Error at Runtime Eric Sosman <esosman@comcast-dot-net.invalid> - 2018-01-05 11:05 -0500
        Re: Unexpected Boxing Error at Runtime bursejan@gmail.com - 2018-01-06 06:18 -0800

Page 2 of 2 — ← Prev page 1 [2]

#37937

Maybe check out:

Can Java 8 do exact arithmetic as in C#
https://groups.google.com/d/msg/comp.lang.java.programmer/11MlDjv-SKI/TZRMa5F-CAAJ

Am Montag, 8. Januar 2018 13:11:03 UTC+1 schrieb burs...@gmail.com:
> Does this have anything to do with Java boxing?
> As far as I know Integer.valueOf doesn't do a range
> 
> check (how should it do it?) and my example also doesn't 
> contain an arithmetic operation such as plus (+).
> 
> My example is about null pointer to Integer conversion:
> 
>      public int getNodesCount() {
>          synchronized (this) {
>              return (children != null ? children.size() : null);
>          }
>      }
> 
> dont get me wrong, its nice to know that you like C#,
> but I really don't see the relevance to the above problem.
> 
> Am Montag, 8. Januar 2018 02:06:58 UTC+1 schrieb Arne Vajhøj:
> > On 1/5/2018 2:59 PM, Daniele Futtorovic wrote:
> > > On 2018-01-05 18:51, Gene Wirchenko wrote:
> > >>       VB 6 defaulted to checking for overflow; this might have just
> > >> been for integer types.  I liked that.  It is far better to find out
> > >> about the error sooner rather than later if ever.
> > > 
> > > YMMV. If I use an integer, I know it might overflow. If I don't want
> > > that, I'll guard against it. I find it borderline insulting when the
> > > language takes that decision away from me. What help is the exception
> > > gonna be in making the program recover, anyway? Yes, it will help to
> > > detect the error. But that only means one hasn't thought things through
> > > in the first place.
> > 
> > I like C# with the check enabled.
> > 
> > using System;
> > 
> > namespace E
> > {
> >      public class Program
> >      {
> >          private static void Avg(int a, int b)
> >          {
> >              Console.WriteLine("Average of {0} and {1} is {2}", a, b, (a 
> > + b) / 2);
> >          }
> >          public static void Main(string[] args)
> >          {
> >              Avg(123, 456);
> >              Avg(int.MaxValue, int.MaxValue);
> >              Console.ReadKey();
> >          }
> >      }
> > }
> > 
> > What is best:
> > 
> > Average of 123 and 456 is 289
> > Average of 2147483647 and 2147483647 is -1
> > 
> > or:
> > 
> > Average of 123 and 456 is 289
> > System.OverflowException: Arithmetic operation resulted in an overflow.
> > 
> > ?
> > 
> > If one really need the integer overflow to work then it is actually
> > still possible by making it explicit.
> > 
> > (I had big problems coming up with an example where it make sense
> > to overflow, but ...)
> > 
> > using System;
> > using System.Text;
> > 
> > namespace E
> > {
> >      public class Program
> >      {
> >          private static int[] Encrypt(int[] a, int k)
> >          {
> >              int[] res = new int[a.Length];
> >              for(int i = 0; i < res.Length; i++)
> >              {
> >                  unchecked
> >                  {
> >                      res[i] = a[i] + k;
> >                  }
> >              }
> >              return res;
> >          }
> >          private static int[] Decrypt(int[] a, int k)
> >          {
> >              return Encrypt(a, -k);
> >          }
> >          private const int KEY = 123456789;
> >          public static void Main(string[] args)
> >          {
> >              int[] a1 = { int.MinValue, -1, 0, 1, int.MaxValue };
> >              int[] a2 = Encrypt(a1, KEY);
> >              int[] a3 = Decrypt(a2, KEY);
> >              for(int i = 0; i < a1.Length; i++)
> >              {
> >                  Console.WriteLine("{0} -> {1} -> {2}", a1[i], a2[i], 
> > a3[i]);
> >              }
> >              Console.ReadKey();
> >          }
> >      }
> > }
> > 
> > works fine even with the check enabled due to the:
> > 
> > unchecked { }
> > 
> > block.
> > 
> > I think this is the right way. Check by default and have a way
> > to disable the check for specific code sections where it is
> > needed.
> > 
> > Arne

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

#37939

On 2018-01-08 13:10, bursejan@gmail.com wrote:
> Does this have anything to do with Java boxing?

No, it doesn't. The thread got sidetracked. Forgive us; we are a bit
starved for material to ramble about.

What you have is perfectly predictable pitfall of Java's autoboxing. You
have to be more careful if you want to avoid it.

-- 
DF.

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

#37945

On 1/8/2018 10:25 AM, Daniele Futtorovic wrote:
> On 2018-01-08 13:10, bursejan@gmail.com wrote:
>> Does this have anything to do with Java boxing?
> 
> No, it doesn't. The thread got sidetracked.

It happens some time.

:-)

Arne

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

#37947

I think Oracle offers courses for this
situation, for about 1500 $ à week, intensive

with a certificate. They gradually start with
easy steps such as switching on and off the

computer, and then proceeds to fundamental
questions where is front and back of the mouse.

I can only recommend, here is a demo video:
https://www.youtube.com/watch?v=dQw4w9WgXcQ

Am Dienstag, 9. Januar 2018 02:06:02 UTC+1 schrieb Arne Vajhøj:
> On 1/8/2018 10:25 AM, Daniele Futtorovic wrote:
> > On 2018-01-08 13:10, bursejan@gmail.com wrote:
> >> Does this have anything to do with Java boxing?
> > 
> > No, it doesn't. The thread got sidetracked.
> 
> It happens some time.
> 
> :-)
> 
> Arne

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

#37941

On Fri, 5 Jan 2018 20:59:45 +0100, Daniele Futtorovic
<da.futt.news@laposte.net> wrote:

>On 2018-01-05 18:51, Gene Wirchenko wrote:
>>      VB 6 defaulted to checking for overflow; this might have just
>> been for integer types.  I liked that.  It is far better to find out
>> about the error sooner rather than later if ever.
>
>YMMV. If I use an integer, I know it might overflow. If I don't want
>that, I'll guard against it. I find it borderline insulting when the

     Or forget about it because you are in a hurry or have other
things to worry about.

     There is very little use for letting an overflow happen.  Garbage
results are garbage.

>language takes that decision away from me. What help is the exception

     Say what?

     "Hey, you might not like having the garbage result due to
overflow."

     "That's borderline insulting."

>gonna be in making the program recover, anyway? Yes, it will help to

     The first step in recovering from an error is to know that there
is one.  Maybe that run is toast, but it may allow for a quick
adjustment.  Ignoring the error can make a real mess.

>detect the error. But that only means one hasn't thought things through
>in the first place.

     Errors happen regardless of thought.  There are many jokes about
"This error should never happen."  I would like to detect as many of
the errors as possible.

Sincerely,

Gene Wirchenko

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

#37942

On 2018-01-08 20:19, Gene Wirchenko wrote:
> On Fri, 5 Jan 2018 20:59:45 +0100, Daniele Futtorovic
> <da.futt.news@laposte.net> wrote:
> 
>> On 2018-01-05 18:51, Gene Wirchenko wrote:
>>>      VB 6 defaulted to checking for overflow; this might have just
>>> been for integer types.  I liked that.  It is far better to find out
>>> about the error sooner rather than later if ever.
>>
>> YMMV. If I use an integer, I know it might overflow. If I don't want
>> that, I'll guard against it. I find it borderline insulting when the
> 
>      Or forget about it because you are in a hurry or have other
> things to worry about.
> 
>      There is very little use for letting an overflow happen.  Garbage
> results are garbage.
> 
>> language takes that decision away from me. What help is the exception
> 
>      Say what?
> 
>      "Hey, you might not like having the garbage result due to
> overflow."
> 
>      "That's borderline insulting."
> 
>> gonna be in making the program recover, anyway? Yes, it will help to
> 
>      The first step in recovering from an error is to know that there
> is one.  Maybe that run is toast, but it may allow for a quick
> adjustment.  Ignoring the error can make a real mess.
> 
>> detect the error. But that only means one hasn't thought things through
>> in the first place.
> 
>      Errors happen regardless of thought.  There are many jokes about
> "This error should never happen."  I would like to detect as many of
> the errors as possible.

> Errors happen regardless of thought.

Not when the something being an error is the result of a thought process
(assigning the quality of being an error to a certain outcome).

You are imputing that an overflow is a garbage result per se. Therefore,
you argue, letting an overflow happen, regardless of whether one thinks
about it or not, is an error. Well, yeah. But that's a strawman.

-- 
DF.

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

#37948

On Mon, 8 Jan 2018 20:40:59 +0100, Daniele Futtorovic
<da.futt.news@laposte.net> wrote:

>On 2018-01-08 20:19, Gene Wirchenko wrote:

[snip]

>> Errors happen regardless of thought.
>
>Not when the something being an error is the result of a thought process
>(assigning the quality of being an error to a certain outcome).

     You mean having a spec -- however detailed or whether written or
not -- for how the program is to behave?  Of course.

     Despite all one's thought on the matter, errors can still happen.
Read up about the Ariane 5 launch that went wrong.  It was due to code
reuse from the Ariane 4.  An assumption that was true on the Ariane 4
was not true about the Ariane 5, and Bad Stuff happened.

>You are imputing that an overflow is a garbage result per se. Therefore,
>you argue, letting an overflow happen, regardless of whether one thinks
>about it or not, is an error. Well, yeah. But that's a strawman.

     It almost always is.  Since it is the exceptional case, let it be
handled exceptionally.

Sincerely,

Gene Wirchenko

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

#37952

On 2018-01-09 03:03, Gene Wirchenko wrote:
> On Mon, 8 Jan 2018 20:40:59 +0100, Daniele Futtorovic
> <da.futt.news@laposte.net> wrote:
>      Despite all one's thought on the matter, errors can still happen.
> Read up about the Ariane 5 launch that went wrong.  It was due to code
> reuse from the Ariane 4.  An assumption that was true on the Ariane 4
> was not true about the Ariane 5, and Bad Stuff happened.
> 
>> You are imputing that an overflow is a garbage result per se. Therefore,
>> you argue, letting an overflow happen, regardless of whether one thinks
>> about it or not, is an error. Well, yeah. But that's a strawman.
> 
>      It almost always is.  Since it is the exceptional case, let it be
> handled exceptionally.

I know about the Ariane 5 thing. And yes, I have to agree that wanting
an overflow is the exceptional case. And that exceptional handling for
it is therefore justified. I prefer it without, at a gut level; but
having thought about it some more, I cannot argue against it intellectually.

-- 
DF.

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

#37976

If you go to FaceBook and Google+ Java programmers
groups, you see a lot of newbees expecting that
an overflow check is the default.

But somehow, when you are from an older generation,
and when you read the Java spec, and see that primitive
types such as int and long are fixed in type sizes,

etc.. etc.. then you remember what a CPU arithmetic
means, and that this is usually, where n depends
on the type sizes:
 
  a +_CPU b = (a + b) mod 2^n

  a -_CPU b = (a - b) mod 2^n

  a *_CPU b = (a * b) mod 2^n

  a /_CPU b = (a / b) mod 2^n

  Etc..

I really admired Java always that they had fixed the
type sizes. In other languages, such as C, it might
easily happen that n varies from platform to platform,

and you need to define your own types, if you want
them to be constant from platform to platform. But well
the overall expectation seems really to be

that languages are more safe or parallel recursion
theory, where we assume unbounded integers. Maybe this
has also to do, that on a higher level, some

applications such as MATLAB etc.. etc.. deliver
the illusion of the recursion theoretic model. Which
might mislead programms that touch Java for the first time.

Am Dienstag, 16. Januar 2018 02:34:13 UTC+1 schrieb Daniele Futtorovic:
> On 2018-01-09 03:03, Gene Wirchenko wrote:
> > On Mon, 8 Jan 2018 20:40:59 +0100, Daniele Futtorovic
> > <da.futt.news@laposte.net> wrote:
> >      Despite all one's thought on the matter, errors can still happen.
> > Read up about the Ariane 5 launch that went wrong.  It was due to code
> > reuse from the Ariane 4.  An assumption that was true on the Ariane 4
> > was not true about the Ariane 5, and Bad Stuff happened.
> > 
> >> You are imputing that an overflow is a garbage result per se. Therefore,
> >> you argue, letting an overflow happen, regardless of whether one thinks
> >> about it or not, is an error. Well, yeah. But that's a strawman.
> > 
> >      It almost always is.  Since it is the exceptional case, let it be
> > handled exceptionally.
> 
> I know about the Ariane 5 thing. And yes, I have to agree that wanting
> an overflow is the exceptional case. And that exceptional handling for
> it is therefore justified. I prefer it without, at a gut level; but
> having thought about it some more, I cannot argue against it intellectually.
> 
> -- 
> DF.

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

#37977

Not sure whether MATLAB is the right example,
but going to Wolfram Alpha gives me easily:

floor(10^36/81)
https://www.wolframalpha.com/input/?i=floor%2810^36%2F81%29

This doesn't fit into a Java int.

Am Montag, 22. Januar 2018 23:26:56 UTC+1 schrieb burs...@gmail.com:
> If you go to FaceBook and Google+ Java programmers
> groups, you see a lot of newbees expecting that
> an overflow check is the default.
> 
> But somehow, when you are from an older generation,
> and when you read the Java spec, and see that primitive
> types such as int and long are fixed in type sizes,
> 
> etc.. etc.. then you remember what a CPU arithmetic
> means, and that this is usually, where n depends
> on the type sizes:
>  
>   a +_CPU b = (a + b) mod 2^n
> 
>   a -_CPU b = (a - b) mod 2^n
> 
>   a *_CPU b = (a * b) mod 2^n
> 
>   a /_CPU b = (a / b) mod 2^n
> 
>   Etc..
> 
> I really admired Java always that they had fixed the
> type sizes. In other languages, such as C, it might
> easily happen that n varies from platform to platform,
> 
> and you need to define your own types, if you want
> them to be constant from platform to platform. But well
> the overall expectation seems really to be
> 
> that languages are more safe or parallel recursion
> theory, where we assume unbounded integers. Maybe this
> has also to do, that on a higher level, some
> 
> applications such as MATLAB etc.. etc.. deliver
> the illusion of the recursion theoretic model. Which
> might mislead programms that touch Java for the first time.
> 
> Am Dienstag, 16. Januar 2018 02:34:13 UTC+1 schrieb Daniele Futtorovic:
> > On 2018-01-09 03:03, Gene Wirchenko wrote:
> > > On Mon, 8 Jan 2018 20:40:59 +0100, Daniele Futtorovic
> > > <da.futt.news@laposte.net> wrote:
> > >      Despite all one's thought on the matter, errors can still happen.
> > > Read up about the Ariane 5 launch that went wrong.  It was due to code
> > > reuse from the Ariane 4.  An assumption that was true on the Ariane 4
> > > was not true about the Ariane 5, and Bad Stuff happened.
> > > 
> > >> You are imputing that an overflow is a garbage result per se. Therefore,
> > >> you argue, letting an overflow happen, regardless of whether one thinks
> > >> about it or not, is an error. Well, yeah. But that's a strawman.
> > > 
> > >      It almost always is.  Since it is the exceptional case, let it be
> > > handled exceptionally.
> > 
> > I know about the Ariane 5 thing. And yes, I have to agree that wanting
> > an overflow is the exceptional case. And that exceptional handling for
> > it is therefore justified. I prefer it without, at a gut level; but
> > having thought about it some more, I cannot argue against it intellectually.
> > 
> > -- 
> > DF.

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

#37921

On 1/4/2018 3:43 PM, Daniele Futtorovic wrote:
> Like the bloody .NET compiler that throws an exception when you overflow
> an integer (by default at least). Annoying. I'm glad Java does a bit
> less hand-holding.

To me it makes sense to make the check default.

If an integer overflows then it seems more likely that
it is a problem than desired behavior.

Arne

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

#37922

On Thu, 04 Jan 2018 19:16:24 -0500, Arne Vajhøj wrote:

> On 1/4/2018 3:43 PM, Daniele Futtorovic wrote:
>> Like the bloody .NET compiler that throws an exception when you
>> overflow an integer (by default at least). Annoying. I'm glad Java does
>> a bit less hand-holding.
> 
> To me it makes sense to make the check default.
> 
> If an integer overflows then it seems more likely that it is a problem
> than desired behavior.
>
Agreed. Anything, such as a variable overflow, that is likely to be a 
design or coding problem merits throwing an exception while something 
that should occur as part of normal processing, like a read encountering 
end of file, should not be an exception.

Java generally has handling for this sort of event about right. 

I picked on EOF as a bad example because the one thing that always pissed 
me off about PL/1 was that it threw an exception on EOF and worse yet, 
the sort of structures you'd normally use to read and process a file 
could not trap the exception. Instead you had to do something ugly like:

dcl eof fixed binary(1);

eof = '0'b;
on endfile(infile) eof = '1'b;

do while(eof = '0'b)
  read file(infile) into(recbuff);
  ...
end;

because although there was a bool() function, PL/1, like C,  doesn't have 
a boolean variable type.


-- 
Martin    | martin at
Gregorie  | gregorie
          | dot org

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

#37920

Dear All,

Thanks for the many responses. Woa,
the situation is quite contrived,

I looked at the byte code, and it seems
that it is translated as:

     public int getNodesCount() {
         synchronized (this) {
        return (children != null ? Integer.valueOf(
                       children.size()) : null).intValue();
     }

So ut seems the if-then-else to gets some type
widening from <nulltype> to Integer.

This makes it impossible for the compiler to spot
the error. Because usually this is spotted:

         int foo = null;

     Error: java: incompatible types: <nulltype>
     cannot be converted to int

Best Regards

P.S.:
Here is the byte code of the if-then-else expression.
The compiler was javac 1.8.0_152:

     GETFIELD DomElement.children : ListArray;
     IFNULL L5
     ALOAD 0
     GETFIELD DomElement.children : ListArray;
     INVOKEVIRTUAL ListArray.size ()I
     INVOKESTATIC java/lang/Integer.valueOf (I)Ljava/lang/Integer;
     GOTO L6
    L5
     ACONST_NULL
    L6
     INVOKEVIRTUAL java/lang/Integer.intValue ()I

j4n bur53 schrieb:
> Dear All,
> 
> By accident I used the following code:
> 
>      public int getNodesCount() {
>          synchronized (this) {
>              return (children != null ? children.size() : null);
>          }
>      }
> 
> It has a subtle error, namely it returns a primitive
> data type, i.e. 'int', but uses automatic boxing.
> 
> But that 'null' cannot be boxed to 'int', is only
> detected at runtime, and not during compile time.
> 
> Is this a bug or feature of Java?

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

#37924

On 1/4/2018 6:13 PM, j4n bur53 wrote:
> [...]
> So ut seems the if-then-else to gets some type
> widening from <nulltype> to Integer.
> 
> This makes it impossible for the compiler to spot
> the error. Because usually this is spotted:
> 
>          int foo = null;
> 
>      Error: java: incompatible types: <nulltype>
>      cannot be converted to int

     For contrast, study

	int foo = (Integer) null;

-- 
esosman@comcast-dot-net.invalid
Eleven hundred eleven days to go.

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

#37932

There exists a further contrast, if I unfold the 
if-then-else expression into an if-then-else statements:

   int k;
   if (children!=null) {
       k=children.size();
   } else {
       k=null;
   }
   return k;

The error would be also spotted.

Am Freitag, 5. Januar 2018 17:05:55 UTC+1 schrieb Eric Sosman:
> On 1/4/2018 6:13 PM, j4n bur53 wrote:
> > [...]
> > So ut seems the if-then-else to gets some type
> > widening from <nulltype> to Integer.
> > 
> > This makes it impossible for the compiler to spot
> > the error. Because usually this is spotted:
> > 
> >          int foo = null;
> > 
> >      Error: java: incompatible types: <nulltype>
> >      cannot be converted to int
> 
>      For contrast, study
> 
> 	int foo = (Integer) null;
> 
> -- 
> esosman@comcast-dot-net.invalid
> Eleven hundred eleven days to go.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web