Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder2.enfer-du-nord.net!feeds.phibee-telecom.net!usenet.ukfsn.org!not-for-mail
From: Martin Gregorie <martin@address-in-sig.invalid>
Newsgroups: comp.lang.java.programmer
Subject: Re: Arithmetic overflow checking
Date: Thu, 21 Jul 2011 12:43:15 +0000 (UTC)
Organization: UK Free Software Network
Lines: 39
Message-ID: <j096t3$7rj$2@localhost.localdomain>
References: <015aeb15-57db-48ab-9cd4-77f8448b632f@w24g2000yqw.googlegroups.com> <knha175c4hu8491pmmek09thqmo7niq3s2@4ax.com> <1f9c17dltrhlmhifuigoa914477r4rg1e1@4ax.com> <l_qdnfmZ-4tpt4vTnZ2dnUVZ_sqdnZ2d@earthlink.com> <koic171t5gas91890r8l9914v26snm7k1v@4ax.com> <b3d4a08b-3428-442a-8cce-30edc2868a47@5g2000yqb.googlegroups.com> <09fe171s46ilvq9qmn254dctunm6noh0ps@4ax.com> <f6ed8d08-bc7a-43e4-aecf-878511705353@j15g2000yqf.googlegroups.com> <4e262731$0$314$14726298@news.sunsite.dk> <j059o8$684$1@dont-email.me> <4e26300b$0$309$14726298@news.sunsite.dk> <cdyVp.5929$Vn5.2217@newsfe18.iad> <4e26b4ed$0$2501$db0fefd9@news.zen.co.uk> <f126e0ad-e1e5-47c8-949e-e38b3598d5ff@m5g2000prh.googlegroups.com> <4e28097f$0$2533$da0feed9@news.zen.co.uk>
NNTP-Posting-Host: 84.45.235.129
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Trace: localhost.localdomain 1311252195 8051 84.45.235.129 (21 Jul 2011 12:43:15 GMT)
X-Complaints-To: usenet@localhost.localdomain
NNTP-Posting-Date: Thu, 21 Jul 2011 12:43:15 +0000 (UTC)
User-Agent: Pan/0.133 (House of Butterflies)
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:6337

On Thu, 21 Jul 2011 12:11:55 +0100, RedGrittyBrick wrote:

> Sure (assuming you're talking about the cost of adding that feature to
> javac and JVM etc), I'm speaking hypothetically.
> 
>     @IntegerOverflowExceptions(true)
>     int c = a + b;
>     @IntegerOverflowExceptions(false)
> 
> It looks horrid to me, and presumably there's lots of issues to
> overcome, better syntax to achieve the same ends, but essentially, if
> Sunacle felt it worthwhile, something could be done to introduce new
> behaviours whilst making them optional for existing code that those
> behaviours would break?
>
Agreed, but there's another way to handle this in Java that would 
probably cater for most overflow and out of range requirements without 
affecting existing programs or the language at all:

Just add range checking constructors to Integer and friends, e.g:

	Integer boundedValue = new Integer(0,1,10);

to declare an Integer, initialised to zero and with the range 1:10. The 
overheads would be minimal if the checks were only enabled if limits were 
added. It could either throw an unchecked exception or provide a range 
checking method: 

	 if (!boundedValue.isInRange()) {...}  

to check the current value or the possibly more useful:

	 if (boundedValue.setChecked( ( a + b ) / c )) {...}


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |