It doesn't really matter. Regardless of the size of the result, what matters is the size of the container (variable) that you store it in. And you will get a compiler error if you try and store something in a variable whose defined size might not be big enough to hold it. Dividing a short by a short using integer division should always yield a short value. Adding two shorts, however, can result in an arithmetic overflow if the results aren't widened to int. Even more so with multiplication, and even subtraction can have an issue.
Java is going to treat arithmetic as a mathematical abstraction while calculating, and the only "real world" considerations are when you exceed the capacity of the largest intermediate data type what the work can be widened to, it will throw an arithmetic exception. But, as I said, don't expect to get away with storing 2 tons of fertilizer in a 1-ton truck. Even if you "know" that the results will always fit, unless the compiler can 100% guarantee a fit, you're not going to be allowed to code for it.
Blitzlügen - Lies or information broadcast, but when called out the broadcaster does little or nothing is done to correct them, thus allowing those who wish to believe to accept them as truth.
Lügensturm - A barrage of Blitzlügen fired in such quick succession that it is essentially impossible to correct them all.
Tim Holloway wrote:. . . . Dividing a short by a short using integer division should always yield a short value.
That is what the mathematical abstraction would say, but Java has different ideas. Arithmetic is always done on types with width 32+ bits, so even if the value fits into the range of a short, it will be perceived as an int There is an exception: where the short is assigned from a compile‑time constant of the appropriate magnitude, in which case an implicit cast is applied. Otherwise the code will fail to compile.
. . . when you exceed the capacity of the largest intermediate data type what the work can be widened to, it will throw an arithmetic exception. . . .
Before Java8, all overflow errors occurred silently and didn't throw exceptions. Whether that was the right decision or wrong……well, I can see arguments on both sides. There are xyzExact() methods, introduced in Java8, which test for overflow and throw an exception if it happens.
You could certainly write your own methods with signatures like boolean isByteSize(long var) and have them test the input to see if it will fit in the data type which is in the method name. They're mostly one-liners, I think.
What you would use them for I don't know, but I'm sure some Java programmer somewhere in the world might find a use for such a thing.
PI day is 3.14 (march 14th) and is also einstein's birthday. And this is merely a tiny ad: