Inconsistent behaviour

[Razvan]

Hi !





Take a look at the following code:


class SimpleJava
{

public static void main(String args[])
{
System.out.println("SimpleJava ....");

SimpleJava sj = new SimpleJava();


System.out.println("Before.");


try {
}
catch(Exception ee) {
System.out.println("Exception caught !");
}

System.out.println("After.");

}
}


It compiles and runs as expected.

Now try this one:


import java.io.*;

class SimpleJava
{

public static void main(String args[])
{
System.out.println("SimpleJava ....");

SimpleJava sj = new SimpleJava();


System.out.println("Before.");


try {
}
catch(IOException ee) {
System.out.println("Exception caught !");
}

System.out.println("After.");

}
}


The second version does not compile ! Compiler error:

SimpleJava.java:19: exception java.io.IOException is never thrown in
body of corresponding try statement
catch(IOException ee) {


Compiler error or expected behavior ?



Regards,
Razvan

 

[Stefan Schulz]

[...]

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?) Whenever you catch Exception, there might be a
RuntimeException...

 

[Tony Morris]

I strongly suggest you read before someone gets really pissed off at you.

http://java.sun.com/docs/books/tutorial/essential/exceptions/index.html

 

[Madhur Ahuja]

Hi ! [snip]
The second version does not compile ! Compiler error:

SimpleJava.java:19: exception java.io.IOException is never thrown in
body of corresponding try statement
catch(IOException ee) {


Compiler error or expected behavior ?

This is taken from one of the earlier post:

To be able to catch a checked exception a method inside the try block
must declare that it throws that exception (or one derived from it).

 

[Thomas G. Marshall]

Madhur Ahuja coughed up:

Hi ! [snip]
The second version does not compile ! Compiler error:

SimpleJava.java:19: exception java.io.IOException is never thrown in
body of corresponding try statement
catch(IOException ee) {


Compiler error or expected behavior ?

This is taken from one of the earlier post:

To be able to catch a checked exception a method inside the try block
must declare that it throws that exception (or one derived from it).

I'm not sure why you think this answers anything.

1. RuntimeException's do not need to be declared to be thrown, so that
statement is false.
2. The OP showed that a try{} actually /worked/.

 

[Razvan]

[...]

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?) Whenever you catch Exception, there might be a
RuntimeException...

Both Exception and IOException are checked. For this reason I
taught that they should behave in the same way. The difference is that
Exception is parent for RuntimeException ...



Regards,
Razvan

 

[Tor Iver Wilhelmsen]

Madhur Ahuja coughed up:

I'm not sure why you think this answers anything.

1. RuntimeException's do not need to be declared to be thrown, so that
statement is false.

RuntimeExceptions are NOT "checked exceptions"! The statement is true.

2. The OP showed that a try{} actually /worked/.

And it worked because Exception is the superclass of RuntimeException,
so a "catch (Exception" can potentially catch unchecked (and hence
undeclared) exceptions. In these cases, it does not need to check the
try block's statements.

 

[Stefan Schulz]

[...]

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?) Whenever you catch Exception, there might be a
RuntimeException...

Both Exception and IOException are checked. For this reason I
taught that they should behave in the same way. The difference is that
Exception is parent for RuntimeException ...

If you catch Exception, you are also catching RuntimeException, so...
strangely enough, Exception can occur even in a block that does not
declare it. (Same with Throwable)

 

[Thomas G. Marshall]

Tor Iver Wilhelmsen coughed up:

"Thomas G. Marshall"


RuntimeExceptions are NOT "checked exceptions"! The statement is true.

You're right, I was incorrect. The unclear point I was making is that his
(only) statement:

Madhur Ahuja:
To be able to catch a checked exception a method inside the try
block must declare that it throws that exception (or one derived
from it).

Does not cover the possibility of RE's.

And it worked because Exception is the superclass of RuntimeException,
so a "catch (Exception" can potentially catch unchecked (and hence
undeclared) exceptions. In these cases, it does not need to check the
try block's statements.

I /know/ that. I was pointing out that Madhur's answer didn't cover the
bases. Even if RE's were not allowed, a single answer in the face of
evidence that it does actually work doesn't make sense.



--
Iamamanofconstantsorrow,I'veseentroubleallmydays.Ibidfarewelltoold
Kentucky,TheplacewhereIwasbornandraised.ForsixlongyearsI'vebeenin
trouble,NopleasureshereonearthIfound.ForinthisworldI'mboundtoramble,
Ihavenofriendstohelpmenow....MaybeyourfriendsthinkI'mjustastrangerMyface,
you'llneverseenomore.ButthereisonepromisethatisgivenI'llmeetyouonGod's
goldenshore.

 

[Madhur Ahuja]

Thomas G. Marshall

Tor Iver Wilhelmsen coughed up:

You're right, I was incorrect. The unclear point I was making is
that his (only) statement:

Madhur Ahuja:
To be able to catch a checked exception a method inside the
try block must declare that it throws that exception (or one
derived from it).

Does not cover the possibility of RE's.



I /know/ that. I was pointing out that Madhur's answer didn't cover
the bases. Even if RE's were not allowed, a single answer in the
face of evidence that it does actually work doesn't make sense.

I was simply making the point that the OP showed the second example with
IOException which is I think a *checked exception* and not a runtime
exception.
According to my statement I previously posted , I think there needs to be
some statement in the try block which throws IOException.

The first example of OP uses Exception class which is superclass of all
exceptions. So it covers the case of runtime exception to which my statement
doesnt applies.

Hope it helps.

 

[Michael Borgwardt]

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.

 

[Stefan Schulz]

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...

 

[LX-i]

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 ~ ~
~ / /\ - | ~ (e-mail address 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++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Thomas G. Marshall]

LX-i coughed up:

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...


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]...

 

[LX-i]

LX-i coughed up:



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 address 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++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Razvan]

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

 

[Razvan]

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

 

[Carl Howells]

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.

 

[Tor Iver Wilhelmsen]

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

 

[Carl Howells]

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.