RFR 8022126: Remove throws SocketException from DatagramPacket constructors accepting SocketAddress

[Michael McMahon]

On 06/08/13 16:57, Alan Bateman wrote:
> On 06/08/2013 08:32, Chris Hegarty wrote:
>> This is a followup to the recent discussion on:
>> http://mail.openjdk.java.net/pipermail/net-dev/2013-July/006889.html
>>   (cont'd) 
>> http://mail.openjdk.java.net/pipermail/net-dev/2013-August/006914.html
>>
>> Two DatagramPacket constructors declare that they throw SocketException.
>>
>>      DatagramPacket(byte[] buf, int len, SocketAddress sa) throws 
>> SocketException
>>      DatagramPacket(byte[] buf, int off, int len, SocketAddress sa) 
>> throws SocketException
>>
>> As it happens 'throws SE' was incorrectly added to these constructors 
>> when introduced in 1.4. The original API specified that SE was thrown 
>> when the given SocketAddress was not supported. That was later 
>> changed to throw IAE, in 1.4.2. These constructor now can never throw 
>> SE.
>>
>> Removing 'throws SE' from the method declaration is a binary 
>> compatible change, but not source compatible ( XXX is never thrown in 
>> body of corresponding try statement ).
>>
>> The conclusion of the discussion is that since these constructors are 
>> not that widely used (the InetAddress+port variants are more 
>> popular). Where they are, the affected code typically sends the 
>> packet, which requires handling of IOException anyway.
>>
>> A note will be added to the jdk8 release notes documenting this 
>> incompatibility.
> While it a source incompatible change, I think it's the right thing to 
> do.
>
> The patch looks fine to me (if you want then the declaration will 
> probably fit on one line now).
>
> -Alan.
Late to this discussion ...

So, the extent of the source compatibility is that a possible user of 
this class may have to
edit their calling code, when recompiling in JDK 8 to possibly remove a 
catch(SocketException)
block, which was dead code that was never being called? I guess that is 
okay especially
since it's not so likely to happen. But, if it does, it will probably 
cause some confusion,
as developers won't be expecting it.

Documenting in release notes is okay too, but I suspect developers are 
not likely to look there
at first anyway. Thinking aloud, it would be nice if some kind of 
annotation could be associated
with the affected constructors such that a more meaningful/customized 
error message
could be emitted by javac. But, perhaps there aren't sufficient other 
use cases to justify that.

Michael.