Inconsistent behaviour

Discussion in 'Java' started by Razvan, Oct 3, 2004.

  1. Razvan

    Razvan Guest

    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
     
    Razvan, Oct 3, 2004
    #1
    1. Advertising

  2. On 3 Oct 2004 12:14:26 -0700, Razvan <> 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?) Whenever you catch Exception, there might be a
    RuntimeException...

    --

    Whom the gods wish to destroy they first call promising.
     
    Stefan Schulz, Oct 3, 2004
    #2
    1. Advertising

  3. Razvan

    Tony Morris Guest

    Tony Morris, Oct 3, 2004
    #3
  4. Razvan

    Madhur Ahuja Guest

    Razvan <> wrote:
    > 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).


    > Regards,
    > Razvan


    --
    Madhur Ahuja [madhur<underscore>ahuja<at>yahoo<dot>com]

    Homepage
    http://madhur.netfirms.com
     
    Madhur Ahuja, Oct 3, 2004
    #4
  5. Madhur Ahuja coughed up:
    > Razvan <> wrote:
    >> 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/.




    >
    >
    >> Regards,
    >> Razvan




    --
    "His name was Robert Paulson. His name was Robert Paulson. His name was
    Robert Paulson..."
     
    Thomas G. Marshall, Oct 4, 2004
    #5
  6. Razvan

    Razvan Guest

    "Stefan Schulz" <> wrote in message news:<opsfa6q3f8q1fd9p@localhost>...
    > On 3 Oct 2004 12:14:26 -0700, Razvan <> 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?) 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
     
    Razvan, Oct 4, 2004
    #6
  7. "Thomas G. Marshall" <> writes:

    > Madhur Ahuja coughed up:
    > > 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.


    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.
     
    Tor Iver Wilhelmsen, Oct 4, 2004
    #7
  8. On 4 Oct 2004 00:07:09 -0700, Razvan <> wrote:

    > "Stefan Schulz" <> wrote in message
    > news:<opsfa6q3f8q1fd9p@localhost>...
    >> On 3 Oct 2004 12:14:26 -0700, Razvan <> 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?) 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)



    --

    Whom the gods wish to destroy they first call promising.
     
    Stefan Schulz, Oct 4, 2004
    #8
  9. Tor Iver Wilhelmsen coughed up:
    > "Thomas G. Marshall"
    > <> writes:
    >
    >> Madhur Ahuja coughed up:
    >>> 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.

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


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


    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.
     
    Thomas G. Marshall, Oct 4, 2004
    #9
  10. Razvan

    Madhur Ahuja Guest

    Thomas G. Marshall
    <> wrote:
    > Tor Iver Wilhelmsen coughed up:
    >> "Thomas G. Marshall"
    >> <> writes:
    >>
    >>> Madhur Ahuja coughed up:
    >>>> 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.

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

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


    --
    Madhur Ahuja [madhur<underscore>ahuja<at>yahoo<dot>com]

    Homepage
    http://madhur.netfirms.com
     
    Madhur Ahuja, Oct 4, 2004
    #10
  11. 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.
     
    Michael Borgwardt, Oct 4, 2004
    #11
  12. On Mon, 04 Oct 2004 22:58:59 +0200, Michael Borgwardt
    <> 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.
     
    Stefan Schulz, Oct 4, 2004
    #12
  13. Razvan

    LX-i Guest

    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.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++++ ~
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     
    LX-i, Oct 5, 2004
    #13
  14. 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,wherethehell'smypen???"
     
    Thomas G. Marshall, Oct 5, 2004
    #14
  15. Razvan

    LX-i Guest

    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 ~ ~
    ~ / /\ - | ~ ~
    ~ _____ / \ | ~ 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++++ ~
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     
    LX-i, Oct 5, 2004
    #15
  16. Razvan

    Razvan Guest

    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, Oct 8, 2004
    #16
  17. Razvan

    Razvan Guest

    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, Oct 8, 2004
    #17
  18. Razvan

    Carl Howells Guest

    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.
     
    Carl Howells, Oct 8, 2004
    #18
  19. Carl Howells <> 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
     
    Tor Iver Wilhelmsen, Oct 9, 2004
    #19
  20. Razvan

    Carl Howells Guest

    Tor Iver Wilhelmsen wrote:
    > Carl Howells <> 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.
     
    Carl Howells, Oct 11, 2004
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ian Davies

    CSS inconsistent behaviour

    Ian Davies, May 14, 2006, in forum: HTML
    Replies:
    6
    Views:
    444
    Neredbojias
    May 18, 2006
  2. =?iso-8859-15?Q?Peter_Kn=F6rrich?=

    Inconsistent float behaviour on "inf" - current state?

    =?iso-8859-15?Q?Peter_Kn=F6rrich?=, Jun 27, 2006, in forum: Python
    Replies:
    1
    Views:
    465
    Scott David Daniels
    Jun 27, 2006
  3. Serengeti
    Replies:
    2
    Views:
    505
    Serengeti
    Nov 20, 2005
  4. Keith Thompson

    Inconsistent behaviour for (1 << 32)

    Keith Thompson, Oct 20, 2007, in forum: C Programming
    Replies:
    8
    Views:
    348
    Daniel Kraft
    Oct 20, 2007
  5. MB

    Inconsistent webservice behaviour

    MB, Dec 8, 2004, in forum: ASP .Net Web Services
    Replies:
    0
    Views:
    150
Loading...

Share This Page