Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Inconsistent behaviour

Reply
Thread Tools

Inconsistent behaviour

 
 
Michael Borgwardt
Guest
Posts: n/a
 
      10-04-2004
Stefan Schulz wrote:
> The behaviour is consistent. You might encounter a RuntimeException in
> any block of code (I know, highly unlikely in a empty block, but how should
> the compiler know?)


Obviously the compiler *can* know that. But it would require a special case
in the language specification, with no real advantage to it.
 
Reply With Quote
 
 
 
 
Stefan Schulz
Guest
Posts: n/a
 
      10-04-2004
On Mon, 04 Oct 2004 22:58:59 +0200, Michael Borgwardt
<(E-Mail Removed)> wrote:

> Stefan Schulz wrote:
>> The behaviour is consistent. You might encounter a RuntimeException in
>> any block of code (I know, highly unlikely in a empty block, but how
>> should
>> the compiler know?)

>
> Obviously the compiler *can* know that. But it would require a special
> case
> in the language specification, with no real advantage to it.


That's what i meant. Otherwise you might argue that a block like
this has no chance to generate a RuntimeException either, and therefore
should not be allowed to throw one:

{
int x = 0;
int y = 1;
int z = x + y;
}

The variations are endless...

--

Whom the gods wish to destroy they first call promising.
 
Reply With Quote
 
 
 
 
LX-i
Guest
Posts: n/a
 
      10-05-2004
Razvan wrote:
>
> try {
> }
> catch(Exception ee) {
> System.out.println("Exception caught !");
> }
>
> It compiles and runs as expected.


Exception is the most-abstract instance of an exception (without being
abstract in and of itself), is it not? I believe you can always catch
"Exception". Whereas, as you've found...

> try {
> }
> catch(IOException ee) {
> System.out.println("Exception caught !");
> }
>
> The second version does not compile ! Compiler error:


Because IOException is a specific exception, and nothing in your try
block would throw it.

> Compiler error or expected behavior ?


I'd call it expected.


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ http://www.velocityreviews.com/forums/(E-Mail Removed) ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~

 
Reply With Quote
 
Thomas G. Marshall
Guest
Posts: n/a
 
      10-05-2004
LX-i coughed up:
> Razvan wrote:
>>
>> try {
>> }
>> catch(Exception ee) {
>> System.out.println("Exception caught !");
>> }
>>
>> It compiles and runs as expected.

>
> Exception is the most-abstract instance of an exception (without being
> abstract in and of itself), is it not? I believe you can always catch
> "Exception". Whereas, as you've found...
>
>> try {
>> }
>> catch(IOException ee) {
>> System.out.println("Exception caught !");
>> }
>>
>> The second version does not compile ! Compiler error:

>
> Because IOException is a specific exception, and nothing in your try
> block would throw it.



Read some of the other replies in this thread to see why your point is
missing the mark.

For this post alone, I'd point out that there is no "specific exception", at
least not in the way you're using. IOException itself has a myriad of
subclasses:

ChangedCharSetException, CharacterCodingException, CharConversionException,
ClosedChannelException, EOFException, FileLockInterruptionException,
FileNotFoundException, HttpRetryException, IIOException,
InterruptedIOException, InvalidPropertiesFormatException,
JMXProviderException, JMXServerErrorException, MalformedURLException,
ObjectStreamException, ProtocolException, RemoteException, SaslException,
SocketException, SSLException, SyncFailedException, UnknownHostException,
UnknownServiceException, UnsupportedEncodingException,
UTFDataFormatException, ZipException




....[rip]...


--
Onedoctortoanother:"Ifthisismyrectalthermometer,wh erethehell'smypen???"



 
Reply With Quote
 
LX-i
Guest
Posts: n/a
 
      10-05-2004
Thomas G. Marshall wrote:
> LX-i coughed up:
>
>>Razvan wrote:
>>
>>>try {
>>>}
>>>catch(Exception ee) {
>>>System.out.println("Exception caught !");
>>>}
>>>
>>>It compiles and runs as expected.

>>
>>Exception is the most-abstract instance of an exception (without being
>>abstract in and of itself), is it not? I believe you can always catch
>>"Exception". Whereas, as you've found...
>>
>>
>>>try {
>>>}
>>>catch(IOException ee) {
>>>System.out.println("Exception caught !");
>>>}
>>>
>>>The second version does not compile ! Compiler error:

>>
>>Because IOException is a specific exception, and nothing in your try
>>block would throw it.

>
>
> Read some of the other replies in this thread to see why your point is
> missing the mark.
>
> For this post alone, I'd point out that there is no "specific exception", at
> least not in the way you're using. IOException itself has a myriad of
> subclasses:
>
> ChangedCharSetException, CharacterCodingException, CharConversionException,
> ClosedChannelException, EOFException, FileLockInterruptionException,
> FileNotFoundException, HttpRetryException, IIOException,
> InterruptedIOException, InvalidPropertiesFormatException,
> JMXProviderException, JMXServerErrorException, MalformedURLException,
> ObjectStreamException, ProtocolException, RemoteException, SaslException,
> SocketException, SSLException, SyncFailedException, UnknownHostException,
> UnknownServiceException, UnsupportedEncodingException,
> UTFDataFormatException, ZipException


I see your point - I didn't use the right terminology. And yes, I've
seen the rest of the thread - when I went to bed last night, I was
actually caught up in here! Thanks for the clarification.


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ (E-Mail Removed) ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~

 
Reply With Quote
 
Razvan
Guest
Posts: n/a
 
      10-08-2004
How about this one:

import java.io.IOException;


public class CDummy
{
public static void main(String args[]) throws IOException
{
System.out.println("CDummy.");
}
}

The main() method declare that it throws IOException (which is
not a parent for RuntimeException), yet the method does not throw an
IOException. The compilation succeeds.



Regards,
Razvan
 
Reply With Quote
 
Razvan
Guest
Posts: n/a
 
      10-08-2004
How about this one:

import java.io.IOException;


public class CDummy
{
public static void main(String args[]) throws IOException
{
System.out.println("CDummy.");
}
}

The main() method declare that it throws IOException (which is
not a parent for RuntimeException), yet the method does not throw an
IOException. The compilation succeeds.



Regards,
Razvan
 
Reply With Quote
 
Carl Howells
Guest
Posts: n/a
 
      10-08-2004
Razvan wrote:
> How about this one:
>
> import java.io.IOException;
>
>
> public class CDummy
> {
> public static void main(String args[]) throws IOException
> {
> System.out.println("CDummy.");
> }
> }
>
> The main() method declare that it throws IOException (which is
> not a parent for RuntimeException), yet the method does not throw an
> IOException. The compilation succeeds.


That's allowed because it actually makes sense for non-static methods.
A non-static method can be overridden, and declaring that it can throw
an exception that the current implementation doesn't allows subclasses
to override the method in a way that can throw the declared exception.

There's just no special case in the JLS for private, static, or final
methods, or methods of final classes, declaring it illegal in those
(usually very few) cases where it doesn't make sense.
 
Reply With Quote
 
Tor Iver Wilhelmsen
Guest
Posts: n/a
 
      10-09-2004
Carl Howells <(E-Mail Removed)> writes:

> Razvan wrote:
> > public static void main(String args[]) throws IOException


> That's allowed because it actually makes sense for non-static methods.


But main() /is/ static...

Perhaps there is special treatment for main(), but I cannot find a
justification for it in the JLS.

However: None of these give compiler errors in my little test class:

public static void main(String[] args) throws IOException {
}

private int foo() throws IOException {
return 2;
}

public static void fie() throws IOException {

}

Compilers: javac from JDK 1.1.8, 1.4.1, 1.4.2 and 1.5.0
 
Reply With Quote
 
Carl Howells
Guest
Posts: n/a
 
      10-11-2004
Tor Iver Wilhelmsen wrote:
> Carl Howells <(E-Mail Removed)> writes:
>
>
>>Razvan wrote:
>>
>>> public static void main(String args[]) throws IOException

>
>
>>That's allowed because it actually makes sense for non-static methods.

>
>
> But main() /is/ static...


Did you read what I said? It's allowed because it makes sense for
methods that can be overridden. And there's no special case disallowing
it for methods that can't be overridden.

I was quite clear. I said exactly what I meant to, and it was correct.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Inconsistent behaviour for (1 << 32) Keith Thompson C Programming 8 10-20-2007 11:59 AM
Inconsistent float behaviour on "inf" - current state? =?iso-8859-15?Q?Peter_Kn=F6rrich?= Python 1 06-27-2006 04:16 PM
CSS inconsistent behaviour Ian Davies HTML 6 05-18-2006 07:20 AM
inconsistent behaviour of const_iterator and const_reverse_iterator Serengeti C++ 2 11-20-2005 01:50 PM
Inconsistent webservice behaviour MB ASP .Net Web Services 0 12-08-2004 08:58 PM



Advertisments