7

I have learnt(atleast in java) that integer/long values overflow silently and their values start over from minimum value on overflow rather than throwing any exception.

I was using an external api for some file operations, in which max file size was being loaded from a property file. All was fine in my local testing environment. As soon as the code went to live environment, the max file size limit was not working at all. After two days of debugging/analyzing the code, there was no success at all. Then for some other reasons, I took the live constants.properties file and debugged the code with that. o_0

I just want to ask, what prevented them to throw exception on overflow?

Aqeel Ashiq
  • 1,988
  • 5
  • 24
  • 57
  • 5
    Performance. Checking for overflow after each math operation is expensive. It would require a compare and a branch, for each add or multiply. – MTilsted Apr 14 '13 at 10:52
  • [Why don't languages raise errors on integer overflow by default?](http://stackoverflow.com/q/103654/995714) – phuclv Jul 02 '15 at 16:34

2 Answers2

6

In many cases Java is based on C or C++ and these are based on Assembly. An overflow/underflow is silent in C and C++ and almost silent in assembly (unless you check special flags). This is likely due to the fact that C and C++ didn't have exceptions when they were first proposed. If you wanted to see overflows/underflows you just used a larger type. e.g. long long int or long double ;) BTW assembly has something similar to exceptions called traps or interrupts, overflows/underflow doesn't cause a trap AFAIK.

What I prefer to do is use long and double unless I am sure these types are much larger than needed. You can't have a device which overflows long in size.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
  • `You can't have a device which overflows long in size`. This statement is worth a million points, a simple fact which doesn't come to mind at first. Thanks. – Aqeel Ashiq Apr 14 '13 at 16:45
  • 1
    Maybe one day there will be one in Java but the file would have to be over 9 billion GB. – Peter Lawrey Apr 15 '13 at 14:22
  • 1
    Perhaps in those times, today's languages would be in I.T. museums. – Aqeel Ashiq Apr 15 '13 at 15:08
  • 4
    Easy with these sorts of statements! ;) Remember "640KB ought to be enough for anybody"? A `long` can describe file/volume sizes only up to about 9 Exa-Byte. Not only is Google operating somewhere in this range right now, it's also only a factor of two million over current 4TB hard-disks. A factor of two million below that was our beloved 3.5" floppy disk, which used to be the standard data carrier just 25 year ago... So, in another quarter century, a single Super-XUHD video from a standard camera might easily break your application. :) Java might survive that long, too... Fortran and C have. – Markus A. May 16 '14 at 05:54
1

The reason is "because the Java Language Specification says so".

Section 4.2.2. Integer Operations of the JLS says:

The integer operators do not indicate overflow or underflow in any way.

To me this makes sense, otherwise you’d need either:

  • an 'NumericOverflowException' to be thrown, which would require a 'try catch', or
  • a flag to be set on the primitive result, which would require a more complex handling of primitive operations

Both of which would make primitives and their operations “not simple”, and simplicity with primitives is a strength not worth sacrificing for a predicable and typically rare occurrence.

Bohemian
  • 412,405
  • 93
  • 575
  • 722
  • 1
    Huh? Why the downvote? How is this answer "not helpful"? (This answer is actually correct) – Bohemian Apr 18 '13 at 17:51
  • +1 unfortunately, the SO community sometimes doesn't like the truth. – Ingo Oct 30 '13 at 15:29
  • The question was looking as to the reason that the language was crafted in this way (hence the word why), pointing to the specification doesn't provide any reasoning. – Jake Hall Dec 30 '14 at 18:46