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 1 of 2  [1] 2  Next page →

#37911 — Unexpected Boxing Error at Runtime

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] | [next] | [standalone]

#37912

On Thursday, January 4, 2018 at 9:17:15 AM UTC-5, j4n bur53 wrote:
> 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?

Apparently it's a gray area, because Integer is supposed to be equivalent to int.  null is the exception so it seems when you tell it to auto-convert Integer to int, it expects you to know you need a non-null value.

If I paste in that method and put in a variable children as the first line as thus I get a warning in Eclipse:
ArrayList<?> children = null;
*warning* = "Null pointer access: This expression of type Integer is null but requires auto-unboxing"

If I change that line to an assignment it ignores the null, apparently assuming it should never hit that branch.
ArrayList<?> children = getArray();

public ArrayList<Object> getArray() {
  return null;
}

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

#37913

On 1/4/2018 9:16 AM, j4n bur53 wrote:
> 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?

     I'd call it an "intentional bug" or "bug by design" (in the
old days we used to say "That's not a bug, that's a feature!").
JLS 5.1.7 lists the various boxing conversions, including "from
the null type to the null type," with a note that the null-null
conversion is required because the conditional operator applies
boxing conversions to its operands.

     Remember, autoboxing was not present in Original Java but was
bolted on afterwards.  Perhaps this is why it sometimes exhibits
certain awkwardnesses, and I think you've found a new one.

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

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

#37914

On Thursday, January 4, 2018 at 9:17:15 AM UTC-5, j4n bur53 wrote:
> 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?

I would expect it's similar to the zero division "bug".  It just expects you to know better.
Even if I hard code it, I don't get a compiler warning, just a runtime error.
int x = 2 / 0;
If you're dividing by a dynamic value such as a method return value, either you must know for certain the method will never return a zero, or you must write a conditional statement to account for the zero possibility.

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

#37915

On 04.01.18 17.01, Eric Douglas wrote:
> I would expect it's similar to the zero division "bug".  It just expects you to know better.
> Even if I hard code it, I don't get a compiler warning, just a runtime error.
> int x = 2 / 0;

Interesting. The same neither compiles in C# nor in C++ because the 
evaluation of compile time constants is done at compile time and there 
is, of course, no reasonable result of this expression.

Java evaluates some compile time constants immediately too. E.g. final 
static values are taken at compile time so changing their values has no 
effect if they are referenced from existing byte code.


Marcel

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

#37916

On Thu, 04 Jan 2018 18:33:57 +0100, Marcel Mueller wrote:

> Interesting. The same neither compiles in C# nor in C++ because the
> evaluation of compile time constants is done at compile time and there
> is, of course, no reasonable result of this expression.
>
the GNU ANSI C compiler also picks it up at compile time, as expected.
 

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

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

#37917

On 1/4/2018 11:01 AM, Eric Douglas wrote:
> [...]
> Even if I hard code it, I don't get a compiler warning, just a runtime error.
> int x = 2 / 0;

     Upon reflection, this isn't too surprising.  JLS 15.17.2
specifies the outcome of attempting integer division by zero:
"[...] if the value of the divisor in an integer division is 0,
then an ArithmeticException is thrown."  That is, the line in
question is roughly equivalent to

	throw new ArithmeticException();  // int x = 2 / 0;

This is a perfectly valid (if not especially useful) statement,
so the compiler must accept it; the compiler would exceed its
authority if it rejected valid (albeit silly) code.

     A warning would be nice, though.

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

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

#37918

On 2018-01-04 21:09, Eric Sosman wrote:
> On 1/4/2018 11:01 AM, Eric Douglas wrote:
>> [...]
>> Even if I hard code it, I don't get a compiler warning, just a runtime
>> error.
>> int x = 2 / 0;
> 
>     Upon reflection, this isn't too surprising.  JLS 15.17.2
> specifies the outcome of attempting integer division by zero:
> "[...] if the value of the divisor in an integer division is 0,
> then an ArithmeticException is thrown."  That is, the line in
> question is roughly equivalent to
> 
>     throw new ArithmeticException();  // int x = 2 / 0;
> 
> This is a perfectly valid (if not especially useful) statement,
> so the compiler must accept it; the compiler would exceed its
> authority if it rejected valid (albeit silly) code.

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.

OP's error is a nasty "feature" though. Then again, many things around
autoboxing are.

-- 
DF.

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

#37919

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).

That depends on what .NET compiler.

For C# the default is no check (compiler - IDE may set the flag by default).

For VB.NET the default is check (again compiler itself).

Arne

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

#37923

On 2018-01-04 21:53, 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).
> 
> That depends on what .NET compiler.
> 
> For C# the default is no check (compiler - IDE may set the flag by
> default).
> 
> For VB.NET the default is check (again compiler itself).

Really? Hmm. Well, it might have been VB. Thanks for the correction.

-- 
DF.

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

#37925

On Fri, 5 Jan 2018 16:06:09 +0100, Daniele Futtorovic
<da.futt.news@laposte.net> wrote:

>On 2018-01-04 21:53, 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).
>> 
>> That depends on what .NET compiler.
>> 
>> For C# the default is no check (compiler - IDE may set the flag by
>> default).
>> 
>> For VB.NET the default is check (again compiler itself).
>
>Really? Hmm. Well, it might have been VB. Thanks for the correction.

     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.

Sincerely,

Gene Wirchenko

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

#37926

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.

-- 
DF.

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

#37927

On Friday, January 5, 2018 at 3:01:18 PM UTC-5, Daniele Futtorovic wrote:
> 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.
> 
> -- 
> DF.

I would guess most programmers don't plan for overflows.  Division by zero usually means data entry error was allowed, or program bug further up the program chain.  We've had programs get masking errors because they only allowed for up to 6 digits in front of the decimal, 20 years ago when a 6 figure order was huge.  Who would've guessed we'd still be running said program recently when 6 figure orders are common and we start to see 7 figures.  While some programmers may literally not care about their code ("I won't be here in 20 years"), some writing code in 1975 may have just assumed all their code would be replaced before the turn of the century so who cares about a 2 digit year.

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

#37929

On Fri, 05 Jan 2018 12:15:21 -0800, Eric Douglas wrote:

Speaking as someone who was there...

> I would guess most programmers don't plan for overflows.  Division by
> zero usually means data entry error was allowed, or program bug further
> up the program chain.
>
IMO undersizing a numeric variable is a design error, regardless of 
whether it was an analyst or a coder who made the mistake. I agree with 
you about divide by zero, though: its probably due to bad input 
validation but might be a pure coding mistake if it occurs somewhere in a 
complex calculation.

> While some programmers may literally not care about their code 
> ("I won't be here in 20 years"),
>
Yep, seen that too, as well as coders who managed to get the same effect 
by sheer incompetence. 

> some writing code in
> 1975 may have just assumed all their code would be replaced before the
> turn of the century so who cares about a 2 digit year.
>
I think there were two things running in parallel that drove this.

- Very few systems on small computers (think ICL 1901, IBM 360/30 or 
  IBM System/3) were expected to last more than 4 or 5 years. 

- Most systems written in the late 60s/early 70s were batch processing
  systems with the data held on cards or tape. These were often simple
  enough that, especially if a hardware upgrade was involved, rewriting
  the system from scratch was quicker and easier than modifying the
  existing code.

- The source was probably a card deck and may have been lost, damaged
  or reshuffled by dropping and we no longer have a card sorter.

- The old code was written in assembler and five years on, all
  development is now in COBOL or some other high-level language, 
  e.g PL/1, RPG or even BASIC. 

Any or all of these taken together mean that a rewrite from scratch 
becomes the obvious move.
 
Second, the date problem. Back in the 60,70s and even into the 80s six 
character dates were the norm, initially because tape capacities and 
computer memories were both small and slow, so NOBODY used four digit 
years unless the system needed to deal with dates before 1900s or later 
than 2000 because of the perceived cost of handling those two extra 
characters on every date. I can only remember two: one was a payroll with 
a few very old people on it who'd been born in the 1890s. The other was a 
music planning system that needed to know composer's birth and death 
dates because concerts celebrating five year anniversaries of a 
composer's birth or death are popular (this needed to handle dates from 
55BC [Euripides birth] to the present).   

In addition, this thinking tended to be encouraged by the system software:

- operating systems didn't have a real-time clock, so the operator input 
the date as part of booting the computer and, as normally no programs 
needed to know the century, why waste time and memory by making the 
operator type it in and the OS store it.

- Some languages did this too. In COBOL a program got the date by 
executing "ACCEPT SYS-DATE FROM DATE." where the Codasyl language 
definition said that the receiving field (SYS-DATE in this example) had 
to be a six character field which ACCEPT would fill with a date formatted 
as YYMMDD. In passing, as late as 2004 I remember seeing an IBM COBOL 
manual which still specified that the ACCEPT receiving field must be six 
characters.


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

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

#37940

On Fri, 5 Jan 2018 21:52:50 +0000 (UTC), Kiwi User
<martin@mydomain.invalid> wrote:

[snip]

>Second, the date problem. Back in the 60,70s and even into the 80s six 
>character dates were the norm, initially because tape capacities and 

     Or worse.

     One regular on alt.folklore.computers related that one task on
his first job was modifying programs to change the hard-coded "6" in
printed dates to "7".  Dates had only one digit for the year.

[snip]

Sincerely,

Gene Wirchenko

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

#37928

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.

     Tastes vary, I guess.  For my part, I would like it if integer
overflow/underflow raised some kind of alert, warning me that one of
my calculations had produced the wrong answer.  See

https://research.googleblog.com/2006/06/extra-extra-read-all-about-it-nearly.html

... for an account (somewhat sensationalized and overexcited) of a bug
that lay latent for nearly a decade but that would have been exposed
much more clearly had integer overflow been noisier.  (Bloch's remarks
about C, even in the "corrected" version, are not quite on the mark.
Also, it is interesting to note that C's "K&R Classic" book from 1978
illustrates a binary search that is *not* vulnerable to the paper's bug.
His point about undetected overflow, however, remains.)

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

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

#37930

On 2018-01-05 22:27, Eric Sosman wrote:
> 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.
> 
>     Tastes vary, I guess.  For my part, I would like it if integer
> overflow/underflow raised some kind of alert, warning me that one of
> my calculations had produced the wrong answer.  See
> 
> https://research.googleblog.com/2006/06/extra-extra-read-all-about-it-nearly.html
> 
> 
> ... for an account (somewhat sensationalized and overexcited) of a bug
> that lay latent for nearly a decade but that would have been exposed
> much more clearly had integer overflow been noisier.  (Bloch's remarks
> about C, even in the "corrected" version, are not quite on the mark.
> Also, it is interesting to note that C's "K&R Classic" book from 1978
> illustrates a binary search that is *not* vulnerable to the paper's bug.
> His point about undetected overflow, however, remains.)

Yeah, I remember reading about that one. The lesson -- humility and the
need for attention to detail -- is certainly a valuable one, and not
limited to overflows.

As you say, tastes vary. Personally, I've taken that habit, whenever I
do integral manipulations, to pause and think of potential overflow. If
I'd written that line in the binary search, I think I would have caught
it (so much for humility ;)). Then again, perhaps I only took that habit
/because/ such lessons cropped up and I heard of them.

I don't mean to sound dogmatic here. Having things that can, if you
want, shield you from making mistakes, at the end of the day, is a good
thing. I guess there's a bit of rancour left in me at that experience in
.NET, one of my first ones, where I had an int that I /wanted/ to
overflow, and felt quite clever about it, and then the runtime came
pissing on my parade like a ruffled mother hen. You could switch it off,
so it was all good, but still.

As for the detection, since there are cases where an overflow is fine,
you can't have the runtime alert you to it, save with the use of some
kind of directives -- compiler directives, annotations, what have you.
In that sense, if you want alerts, .NET's way is probably the only
practical one.

I still prefer Java's Live & Let Die, though. Keeps you on your toes.
-- 
DF.

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

#37931

On Sat, 06 Jan 2018 00:06:20 +0100, Daniele Futtorovic wrote:

> As you say, tastes vary. Personally, I've taken that habit, whenever I
> do integral manipulations, to pause and think of potential overflow.
>
It surprises me that anybody would not to that, but then again maybe I've 
done a lot more work on 8-bit (6800) and 8/16-bit (6809) chips than those 
who've not programmed anything before 32-bit systems became dominant.

The difference was that RAM was usually smaller than the theoretical 
address space, but an index variable frequently had a smaller range than  
the installed RAM.


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

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

#37933

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]

#37934

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]

Page 1 of 2  [1] 2  Next page →

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

csiph-web