Difference between programmer-defined exception and exception defined in the Java core API

[Nyeng Gyang]

The following code understandably causes a compile-time error, because the code in the try block will never throw a checked exception (i.e., a MyExceptionClass class exception), which means that the catch block code is unreachable:

class MyExceptionClass extends Exception{}

public class TestExceptions
{
   public void method1()
   {
      try
      {
         method2();
      }
      catch(MyExceptionClass e)
      {
         System.out.print("");
      }
   }
   
   public void method2()
   {
   }
   
   public static void main(String... a)
   {
   }  
}

The exact error the compiler reports is as follows:

TestExceptions.java:11: error: exception MyExceptionClass is never thrown in body of corresponding try statement
      catch(MyExceptionClass e)
      ^
1 error

Since the reason why the code above causes a compile-time error is understandable, the question is why the following code should not also cause a compile-time error, since the code in the try block should also never throw a checked exception (i.e., an Exception class exception); in fact, the same result (of no compile-time error) is still obtained even when the try block is empty (i.e., having no code within its braces):

public class TestExceptions
{
   public void method1()
   {
      try
      {
         int a;
      }
      catch(Exception e)
      {
         System.out.print("");
      }
   }
   
   public void method2()
   {
   }
   
   public static void main(String... a)
   {
   }  
}

The only difference between the first and second code chunks is that the exception being attempted to be caught (in the catch block) is of a programmer-defined checked exception class (in the first code chunk) and a checked exception class defined in the Java core API (in the second code chunk). Is this difference what is causing the compile-time error for the first code chunk, but not for the second code chunk?

[Campbell Ritchie]

Nyeng Gyang wrote:. .  the exception . . . is of a programmer-defined checked exception class . . . and a checked exception class defined in the Java core API . . .

Waht about subtypes of Exception already defined by the standard API?

class MyExceptionClass extends Exception{}

public class TestExceptions
{
   public void method1()
   {
      try
      {
         method2();
      }
      catch(FileNotFoundException e)
      {
         System.out.print("");
      }
   }
   
   public void method2()
   {
   }
   
   public static void main(String... a)
   {
   }  
}

The only change is in line 11. Try that code and see what happens.

[Matthew Bendford]

I'm not sure about it, but a possible reason could that the compiler optimize it away as the only statement in the try block is declaring a local member, which does not cause any side effect and hence is equal to the whole try/catch be removed. As the try/catch itself is optimized away it doesn't matter to check if the catch is reachable.

[Campbell Ritchie]

What an interesting point you noticed. I think it is too difficult a point for “beginning” so I have moved you.

I don't think there is any difference between a subtype of Exception declared by the user and one implemented by a designer of the language. What does matter, however, is the difference between Exception and any of its subclasses. The Java® Language Specification (=JLS) says that there is an exception to the rule that all checked exceptions caught must have a try that actually throws that type of exception.

That JLS section wrote:It is a compile-time error if a catch clause can catch checked exception class E₁ and it is not the case that the try block corresponding to the catch clause can throw a checked exception class that is a subclass or superclass of E₁, unless E₁ is Exception or a superclass of Exception.

So it is always permitted to catch Exception or its supertype Throwable.
I think (not certain) that the compiler will reinterpret catch (Exception...)... to catch whichever checked exception types are declared in the try, but I am by no means sure on that point.

[Stephan van Hulst]

It's not so difficult: Exception is the supertype of not only checked exceptions, but also some unchecked exceptions. By their very nature, unchecked exceptions are not checked. The compiler simply does not check whether your try-clause can throw any unchecked exceptions (even if you, the programmer, can easily reason that it won't). Since it doesn't know that the try-clause won't throw any unchecked exceptions, it allows catching Exception in case an unchecked exception is thrown.

Simply put, you may ALWAYS catch an exception type that is a supertype of an unchecked exception. That not only includes any RuntimeException, but also Exception, Throwable and any Error.

[Stephan van Hulst]

Here is some code to illustrate my point:

final class ExceptionTest {

  void trySomething() {
    try {
      doSomething();
    }

    catch (Exception ex) {
      System.err.println("We caught an unchecked exception!");
    }
  }

  void doSomething() {
    var kaboom = 42 / 0;
  }
}

[Nyeng Gyang]

Campbell Ritchie wrote:The only change is in line 11. Try that code and see what happens.

I tried the code with the FileNotFoundException replacing the Exception in the catch block and the result is the same (i.e., the first code chunk still causes the same compile-time error; see below).

TestExceptions.java:12: error: exception FileNotFoundException is never thrown in body of corresponding try statement
      catch(FileNotFoundException e)
      ^
1 error

[Nyeng Gyang]

Matthew Bendford wrote:I'm not sure about it, but a possible reason could that the compiler optimize it away as the only statement in the try block is declaring a local member, which does not cause any side effect and hence is equal to the whole try/catch be removed. As the try/catch itself is optimized away it doesn't matter to check if the catch is reachable.

The reasoning you have employed here is a quite good, plausible explanation for why the second code chunk does not cause the compile-time error.

In other words, if the code in the try block is trivial (in terms of throwing a checked exception), does not cause any side effects and is, therefore, equivalent to the try block being empty (i.e., having no code within its braces) then the compiler performs optimization that entails replacing the try-catch block code with code in which this block is simply non-existent/removed.

The utility of the compiler optimization would be based on the following: The triviality of the code in the try block (which is defined in terms of throwing a checked exception) justifies the compiler treating the code as though the try-catch block were not in the code at all and, therefore, precludes the need for the compiler to generate/report an error.

[Campbell Ritchie]

Stephan van Hulst wrote:. . . The compiler simply does not check . . . unchecked exceptions (even if you, the programmer, can easily reason that it won't). . . .

What about arithmetic exceptions, when you cannot reason that the divisor isn't 0? What about null pointer exception if you haven't taken precautions to exclude nulls?

[Stephan van Hulst]

Campbell Ritchie wrote:What about arithmetic exceptions, when you cannot reason that the divisor isn't 0? What about null pointer exception if you haven't taken precautions to exclude nulls?

Yes, all of these are exceptions that can be thrown that the compiler won't check for. Since they are subtypes of RuntimeException and therefore Exception, the compiler will allow you to catch them using a catch (Exception ex) clause, even if they aren't declared in a throws declaration. See my code example above.

[Nyeng Gyang]

Campbell Ritchie wrote:I think it is too difficult a point for “beginning” so I have moved you.

Thanks for doing this. I did not realize that I made this post under the "beginning" area of the website.

The JLS quote you provided only reinforces the question I asked, namely: Why doesn’t the second code chunk also cause the compile-time error since the code in the try block cannot throw a checked exception of the Exception class or any of its subclasses.

By the way, I believe that there is a small mistake in the explanation provided, in that JLS quote you provided, for why a compile-time error will be caused when there is a certain combination of code in a try block and the corresponding exception class provided in the corresponding catch block. I think that the correct explanation should be as follows, rather than how it is as you have quoted it: “It is a compile-time error if a catch clause can catch checked exception class E₁ and it is not the case that the try block corresponding to the catch clause can throw a checked exception class that is a subclass or superclass of E₁ ....”

The modification that I have provided to the quote that you have provided is because the exception thrown in the try block may only be either of the same class as, or a subclass of, the exception class provided in the corresponding catch block, but not of a superclass of the exception class provided in the corresponding catch block.

[Stephan van Hulst]

Nyeng Gyang wrote:

Matthew Bendford wrote:I'm not sure about it, but a possible reason could that the compiler optimize it away as the only statement in the try block is declaring a local member, which does not cause any side effect and hence is equal to the whole try/catch be removed. As the try/catch itself is optimized away it doesn't matter to check if the catch is reachable.

The reasoning you have employed here is a quite good, plausible explanation for why the second code chunk does not cause the compile-time error.

It is also, sadly, mistaken. Try-statements are never optimized away.

[Stephan van Hulst]

Nyeng Gyang wrote:The JLS quote you provided only reinforces the question I asked, namely: Why doesn’t the second code chunk also cause the compile-time error since the code in the try block cannot throw a checked exception of the Exception class or any of its subclasses.

Because of the piece of the quote that says: "unless E₁ is Exception or a superclass of Exception."

The modification that I have provided to the quote that you have provided is because the exception thrown in the try block may only be either of the same class as, or a subclass of, the exception class provided in the corresponding catch block, but not of a superclass of the exception class provided in the corresponding catch block.

Untrue.

If you declare FileNotFoundException in a catch-clause, that is absolutely valid if the code in the try-clause can throw IOException, even through IOException is a supertype of FileNotFoundException.

[Nyeng Gyang]

Stephan van Hulst wrote:By their very nature, unchecked exceptions are not checked. The compiler simply does not check whether your try-clause can throw any unchecked exceptions (even if you, the programmer, can easily reason that it won't).

My issue is not about your factual information that the compiler does not enforce the "handle or declare" rule for unchecked exceptions.

[Nyeng Gyang]

Stephan van Hulst wrote:It is also, sadly, mistaken. Try-statements are never optimized away.

Thanks for this information.

[Nyeng Gyang]

Stephan van Hulst wrote:If you declare FileNotFoundException in a catch-clause, that is absolutely valid if the code in the try-clause can throw IOException, even through IOException is a supertype of FileNotFoundException.

Have you actually tried this and actually run the code to see that it will compile? I have done so and the code definitely does not compile when the catch block exception is FileNotFoundException and the exception thrown in the try block is IOException.

[Stephan van Hulst]

The JLS gives you an answer to your question: If you declare Exception (or Throwable) in a catch clause, it is not required that any of the code in your try-clause declares that it throws an exception because Exception is a special case!

That JLS section wrote:unless E₁ is Exception or a superclass of Exception.

Then I went on to give you an explanation for why this exception (hehe) is made for the Exception class. I did this so that you would get a more satisfying answer than "Because the JLS says so".

That explanation is that Exception is not only the supertype of checked exceptions, it is also the supertype of some unchecked exceptions. That means that a programmer might want to catch Exception even though no line of code in the try-clause declares that it throws an exception, because it is still possible to catch unchecked exceptions such as arithmetic exceptions or null reference exceptions.

[Stephan van Hulst]

Nyeng Gyang wrote:Have you actually tried this and actually run the code to see that it will compile? I have done so and the code definitely does not compile when the catch block exception is FileNotFoundException and the exception thrown in the try block is IOException.

I don't know what you tried, but this compiles just fine:

  void throwIOException() throws IOException {
    try {
      throw new IOException();
    }
 
    catch (FileNotFoundException ex) {
      // this will never happen, but it is still allowed.
    }
  }

[Campbell Ritchie]

Stephan van Hulst wrote:. . . I don't know what you tried . . .

Probably the same as I posted here.

Campbell's JShell (JDK15) wrote:Error:
|  exception java.io.FileNotFoundException is never thrown in body of corresponding try statement
|                catch(FileNotFoundException e)

Obviously the compiler thinks the IOException might include a file not found exception, in which case the catch will be executed. If it isn't banned by the JLS, the compiler has to permit it.
[addition]Your code can handle an IO exception which isn't file not found by declaring it might throw it.

[Matthew Bendford]

Stephan van Hulst wrote:

Nyeng Gyang wrote:

Matthew Bendford wrote:I'm not sure about it, but a possible reason could that the compiler optimize it away as the only statement in the try block is declaring a local member, which does not cause any side effect and hence is equal to the whole try/catch be removed. As the try/catch itself is optimized away it doesn't matter to check if the catch is reachable.

The reasoning you have employed here is a quite good, plausible explanation for why the second code chunk does not cause the compile-time error.

It is also, sadly, mistaken. Try-statements are never optimized away.

Thanks for that information - wasn't aware of that.
I had the supertype Exception suspected to have some special meaning as it's the root for both all checked exceptions, but also the supertype of RuntimeException.
In fact, I'm aware that one can always catch Throwable, Error and Exception without the try-block actually throw them in specific (in fact, Error should never be caught).

[Nyeng Gyang]

Stephan van Hulst wrote:The JLS gives you an answer to your question: If you declare Exception (or Throwable) in a catch clause, it is not required that any of the code in your try-clause declares that it throws an exception because Exception is a special case!

Just so that we are all clear that you actually understand the gist of the issue I raised in my initial post above, which started this entire discussion thread, kindly use your own words to express/explain this point that I raised. I ask you to do this because virtually all of your responses are not actually addressing the point I raised. Thanks in advance!

[Nyeng Gyang]

Stephan van Hulst wrote:I don't know what you tried, but this compiles just fine:

If the code you provided would successfully compile, my guess, of the reason why the code would compile successfully, is because the throwIOException() method you implemented in the code declares that it does not handle the IOException that it throws in its body. Since the method declares (i.e., throws) the exception, my guess is that the compiler would not check to see whether the body of the method actually handles it. Since the compiler does not perform a check whether the exception thrown in the try block is handled (in the catch block), the compiler does not detect the compile-time error of a programmer throwing an exception of class E in a try block and placing an exception of a subclass of class E in the corresponding catch block (an example of this compile-time error is what happens when the catch block exception is of the FileNotFoundException class and the exception thrown in the try block is of the IOException class).

The fact that you have provided the code, with the throwIOException() method, as an example to demonstrate the inaccuracy of a claim I made simply demonstrates and illustrates, without a doubt, that this claim I made is yet another issue I raised that you haven’t truly wrapped your head around. (By the way, this claim that I made is that the aforementioned JLS quote should be modified with the correction I have provided, namely: It is a compile-time error to throw an exception of class E in a try block and place an exception of a subclass of class E in the corresponding catch block. Like I have already explained in the foregoing, your example throwIOException() method is code that doesn’t meet this condition, which is why it would compile successfully, assuming that it actually would compile successfully.) In order to determine whether this claim that I have made is inaccurate or not, the correct code you should use to test the claim is the following one, not the code with the throwIOException() method that you used and provided here:

import java.io.*;
public class ThrowingExceptions
{   
   public static void main(String... a)
   {
      try
      {
         throw new IOException();
      }
      catch(FileNotFoundException e)
      {
      }
   }   
}

Please, do us all a favor, by copying this code exactly, place it in a file named ThrowingExceptions.java and then attempt to compile the code in this .java file. When you do this, you will notice that the following is the exact error the compiler reports:

ThrowingExceptions.java:8: error: unreported exception IOException; must be caught or declared to be thrown
         throw new IOException();
         ^
1 error

[Nyeng Gyang]

Stephan van Hulst wrote:I don't know what you tried, but this compiles just fine:

On a second thought, I decided to check to see whether your claim is true that the code, with the throwIOException() method, which you provided, successfully compiles. After doing this check/test using the following code, I discovered that even that code doesn’t actually successfully compile:

import java.io.*;
public class ThrowingExceptions
{
   public static void throwIOException() throws IOException
   {     
      try
      {
         throw new IOException();
      }
      catch(FileNotFoundException e)
      {
      }
   }   
   public static void main(String... a)
   {
      try
      {         
         throwIOException();
      }
      catch(FileNotFoundException e)
      {
      }
   }   
}

Once again, please, do us all a favor, by copying this code exactly, place it in a file named ThrowingExceptions.java and then attempt to compile the code in this .java file. When you do this, you will notice that the following is the exact error the compiler reports:

ThrowingExceptions.java:18: error: unreported exception IOException; must be caught or declared to be thrown
         throwIOException();
                         ^
1 error

[Campbell Ritchie]

No, what you have done is move the compiler error. The method similar to what Stephan wrote seems to compile normally, but the main() method now has an unhandled exception. So Stephan's argument remains correct.
Please have another look at the JLS link I posted in my second post yesterday. Does it say anything about exception classes and their supertypes being acceptable as catch parameters?

[Stephan van Hulst]

Nyeng Gyang wrote:Just so that we are all clear that you actually understand the gist of the issue I raised in my initial post above, which started this entire discussion thread, kindly use your own words to express/explain this point that I raised. I ask you to do this because virtually all of your responses are not actually addressing the point I raised. Thanks in advance!

You are asking why the compiler complains about you catching MyExceptionClass when that exception is not thrown by the code in the corresponding try-clause, while the compiler doesn't complain about you catching Exception, when that exception is not thrown by the code in the corresponding try-clause.

Since the method declares (i.e., throws) the exception, my guess is that the compiler would not check to see whether the body of the method actually handles it.

False. A throws declaration does not disable exception checking. It just allows you to leave exceptions of that type uncaught.

Since the compiler does not perform a check whether the exception thrown in the try block is handled (in the catch block), the compiler does not detect the compile-time error of a programmer throwing an exception of class E in a try block and placing an exception of a subclass of class E in the corresponding catch block

False. The compiler doesn't raise an error, not because exception checking is disabled, but because it simply is not a compile-time error to catch an exception of a sub-type of a checked exception that can be thrown in the try-clause, as the JLS explicitly says.

If a throws declaration really disabled exception checking, this would not compile either, but it does:

  void doNothingSlowly() {
    try {
      throw new IOException();
    }
 
    catch (FileNotFoundException ex) {
      // this will never happen, but it is still allowed.
    }
    
    catch (IOException ex) {
      // this will happen.
    }
  }

Unless you're gonna say that catching an exception instead of using a throws declaration also disables exception checking for that exception type, in which case there simply is no point in arguing with you.

this claim that I made is that the aforementioned JLS quote should be modified with the correction I have provided

Yes, and your correction is wrong. The JLS is correct.

Let's take a closer look at your 'correction', shall we?

It is a compile-time error to throw an exception of class E in a try block and place an exception of a subclass of class E in the corresponding catch block.

I threw an exception of class IOException in the try-clause. I caught an exception of a subclass of IOException in the corresponding catch-clause. Where is my compile-time error?

When you do this, you will notice that the following is the exact error the compiler reports:

ThrowingExceptions.java:18: error: unreported exception IOException; must be caught or declared to be thrown
         throwIOException();
                         ^
1 error

The compiler is literally telling you that your main() method is wrong, not my throwIOException() method.

[Campbell Ritchie]

Sorry, but I have only just noticed this post of yours.

Nyeng Gyang wrote:. . . By the way, I believe that there is a small mistake in the explanation provided, in that JLS quote . . . the correct explanation should be as follows, rather than how it is as you have quoted it . . ..

I have checked that JLS link again and it is quoted correctly. It also includes something about superclasses, which Stephan told you about. If you don't understand the JLS, and some of the JLS is hard to understand, please ask for more explanation rather than trying to alter the JLS. All that achieves is to introduce errors into the discussion.

[Nyeng Gyang]

Stephan van Hulst wrote:You are asking why the compiler complains about you catching MyExceptionClass when that exception is not thrown by the code in the corresponding try-clause, while the compiler doesn't complain about you catching Exception, when that exception is not thrown by the code in the corresponding try-clause.

The following points better state the issue I raised:

(1.) The compiler determines that it is an error to attempt to catch a checked exception, in a catch block, when the code in the corresponding try block cannot possibly throw the checked exception attempted to be caught in the try block.

(2.) The compiler makes the determination mentioned in point number 1 above only when the checked exception in question is of a checked exception class defined in the Java core API, but not when the checked exception is of a programmer-defined checked exception class. (Recall that MyExceptionClass  extends Exception.)

(3.) When making the error determination mentioned in point number 1 above, why does the compiler treat a checked exception of a checked exception class defined in the Java core API differently than it treats a checked exception of a programmer-defined checked exception class?

[Nyeng Gyang]

Stephan van Hulst wrote:I threw an exception of class IOException in the try-clause. I caught an exception of a subclass of IOException in the corresponding catch-clause. Where is my compile-time error?

You only provided a standalone method, not complete code that we can test whether it successfully compiles or not. In order to check/test that your method successfully compiles, the following code is the minimum amount of code that must be used (in order to eliminate all other errors not related to the specific error in the method) and this code certainly does not compile successfully:

import java.io.*;
public class ThrowingExceptions
{
   public static void throwIOException() throws IOException
   {     
      try
      {
         throw new IOException();
      }
      catch(FileNotFoundException e)
      {
      }
   }   
   public static void main(String... a) 
   {
      try
      {         
         throwIOException();
      }
      catch(FileNotFoundException e)
      {
      }
   }   
}

Like I have already said, please, attempt to compile the foregoing code and see for yourself that the following is the exact error the compiler reports:

ThrowingExceptions.java:18: error: unreported exception IOException; must be caught or declared to be thrown
         throwIOException();
                         ^
1 error

The foregoing error reported by the compiler should answer the following question you asked: "Where is my compile-time error?" (In other words, after your code threw an exception of class IOException in the try-clause and then sought to catch an exception of a subclass of IOException in the corresponding catch-clause, the foregoing error gets reported.)

Please note the following points I made in a previous post I made above:

(1.) "The fact that you have provided the code, with the throwIOException() method, as an example to demonstrate the inaccuracy of a claim I made simply demonstrates and illustrates, without a doubt, that this claim I made is yet another issue I raised that you haven’t truly wrapped your head around."

(2.) "In order to determine whether this claim that I have made is inaccurate or not, the correct code you should use to test the claim is the following one, not the code with the throwIOException() method that you used and provided here:"

import java.io.*;
public class ThrowingExceptions
{   
   public static void main(String... a)
   {
      try
      {
         throw new IOException();
      }
      catch(FileNotFoundException e)
      {
      }
   }   
}

The following is the exact error the compiler reports for the second code chunk above:

ThrowingExceptions.java:8: error: unreported exception IOException; must be caught or declared to be thrown
         throw new IOException();
         ^
1 error

[Nyeng Gyang]

Campbell Ritchie wrote:The method similar to what Stephan wrote seems to compile normally ...

Like I already explained in my response to Stephan, he provided the wrong code to demonstrate his claimed inaccuracy of a claim I made. In order to check/test whether or not my claim is inaccurate, the following code is the code that must be used and this code certainly does not compile successfully:

import java.io.*;
public class ThrowingExceptions
{   
   public static void main(String... a)
   {
      try
      {
         throw new IOException();
      }
      catch(FileNotFoundException e)
      {
      }
   }   
}

Like I have also already advised Stephan, please, attempt to compile the foregoing code and see for yourself that the following is the exact error the compiler reports:

ThrowingExceptions.java:8: error: unreported exception IOException; must be caught or declared to be thrown
         throw new IOException();
         ^
1 error

[Nyeng Gyang]

Campbell Ritchie wrote:No, what you have done is move the compiler error. ... but the main() method now has an unhandled exception. So Stephan's argument remains correct.

I am truly not sure what you mean by my having moved the compiler error or by the main() method now having an unhandled exception. Anyways, it is not true that the main() method I provided does not handle the exception thrown in the main() method and this is simply because the IOException, which is thrown in the main() method, is placed in a try block and a corresponding catch block is provided for this try block.

If, by making the remarks I quoted above, you are making the argument that the try and catch blocks provided in the main() method are not adequate for successfully catching the particular thrown exception (i.e., the IOException) then you are indeed making my point, which is as follows: "It is a compile-time error when the catch block exception is of the FileNotFoundException class and the exception thrown in the try block is of the IOException class)"

[Nyeng Gyang]

Campbell Ritchie wrote:Please have another look at the JLS link I posted in my second post yesterday. Does it say anything about exception classes and their supertypes being acceptable as catch parameters?

The following is the JLS quote you provided: “It is a compile-time error if a catch clause can catch checked exception class E₁ and it is not the case that the try block corresponding to the catch clause can throw a checked exception class that is a subclass or superclass of E₁, unless E₁ is Exception or a superclass of Exception.”

The following is my correction to the quote you provided: “It is a compile-time error if a catch clause can catch checked exception class E₁ and it is not the case that the try block corresponding to the catch clause can throw a checked exception class that is a subclass or superclass of E₁ ....”

The JLS quote definitely claims that it is not a compile-time error if a catch clause can catch a checked exception class E₁ and it is the case that the try block corresponding to the catch clause can throw a checked exception class that is a subclass or superclass of E₁. I am saying that this claim is wrong, because of the following facts:

(1) It is not a compile-time error if an exception of class E₁ is thrown in a try block and the corresponding catch block catches a superclass of E₁.

(2.) It is a compile-time error if an exception of class E₁ is thrown in a try block and the corresponding catch block catches a subclass of E₁.

[Campbell Ritchie]

Nyeng Gyang wrote:. . . I am truly not sure what you mean by my having moved the compiler error

The earlier examples had a compile time error in the throwIOException() method and you now have an error in the main() method. It is to all intents and purposes the same error.

or by the main() method now having an unhandled exception.

The throwIOException() method declares that it might suffer a checked exception and that it cannot handle it itself. The method calling it must therefore deal with that exception if it occurs. So main() must either catch that exception or declare that it might throw it.
To repeat: the throwIOException() method declares IOException; the compiler “believes” that. Have a look in the Java™ Tutorials.

Anyways, it is not true that the main() method I provided does not handle the exception . . . the IOException, which is thrown in the main() method, is placed in a try block and a corresponding catch block is provided for this try block.

Afraid you are mistaken on both counts. The full range of exceptions possibly thrown is not handled in either method.

[Campbell Ritchie]

Nyeng Gyang wrote:. . . The JLS quote definitely claims . . .

The JLS doesn't claim anything anywhere. It instructs things. If it says that is how catch blocks are to be designed, then all implementers must follow those instructions or their code won't be permissible as a Java® implementation.

[Nyeng Gyang]

Campbell Ritchie wrote:The JLS doesn't claim anything anywhere. It instructs things. If it says that is how catch blocks are to be designed, then all implementers must follow those instructions or their code won't be permissible as a Java® implementation.

Of course, the JLS instructs and, by the way, any such instruction also comprises claims of what is legal or illegal in Java programming. However, the instruction provided by the JLS should not contradict how a compiler determines what is legal or illegal.

[Nyeng Gyang]

Campbell Ritchie wrote:The throwIOException() method declares that it might suffer a checked exception and that it cannot handle it itself. The method calling it must therefore deal with that exception if it occurs.

Again, I will keep repeating myself until either you or Stephan finally understands that producing the wrong code to demonstrate his claimed inaccuracy of a claim I made only makes our discussion here very intractable and unproductive. Insisting that the code he provided, rather than the one I have provided, is what is required to invalidate my claim only demonstrates that you two are yet to wrap your heads around the claim I have made, a claim we all have repeated several times.

And, by the way, kindly do read a previous post I made above to better understand my factual claim that, because my provided main method actually handles the exception thrown in the method, it needs not declare the exception.

[Stephan van Hulst]

Nyeng Gyang wrote:(1.) The compiler determines that it is an error to attempt to catch a checked exception, in a catch block, when the code in the corresponding try block cannot possibly throw the checked exception attempted to be caught in the try block.

This is true, but the JLS gives a special exception from this rule if the exception to be caught is declared as Exception or Throwable in the catch-clause.

(2.) The compiler makes the determination mentioned in point number 1 above only when the checked exception in question is of a checked exception class defined in the Java core API, but not when the checked exception is of a programmer-defined checked exception class. (Recall that MyExceptionClass  extends Exception.)

This is not true. The compiler raises an error for ALL checked exception types, not just programmer defined exceptions, EXCEPT Exception and Throwable. Recall that IOException also extends Exception and the compiler raises the same issues that it does for MyExceptionClass.

(3.) When making the error determination mentioned in point number 1 above, why does the compiler treat a checked exception of a checked exception class defined in the Java core API differently than it treats a checked exception of a programmer-defined checked exception class?

It literally doesn't. I really have no idea how you came to this conclusion. You derived your conclusion from the fact that the compiler doesn't complain when you catch Exception, but as we've said Exception is a SPECIAL CASE. It does raise an error when you try to catch OTHER checked exceptions from the standard API:

final class ExceptionTest {

  void willNotCompile() {
    try {
      var kaboom = 42 / 0;
    }
    
    catch (IOException ex) {
      // This time the compiler will raise an error,
      // because the try-clause can under no circumstance throw an IOException.
      //
      // Notice how IOException is an exception from the standard API, and not programmer defined?
    }
  }
}

Nyeng Gyang wrote:You only provided a standalone method, not complete code that we can test whether it successfully compiles or not.

I thought that you would be able to wrap the method declaration in a class declaration on your own. Here you go, it compiles:

final class ExceptionTest {

  void doNothingSlowly() {
    try {
      throw new IOException();
    }
 
    catch (FileNotFoundException ex) {
      // this will never happen, but it is still allowed.
    }
    
    catch (IOException ex) {
      // this will happen.
    }
  }
}

Like I have already said, please, attempt to compile the foregoing code and see for yourself that the following is the exact error the compiler reports

And as I've already said, that error is caused because you didn't write the main() method correctly. My throwIOException() and doNothingSlowly() methods compile just fine, as you can see from the code I just posted again. That means that the fact that it catches a FileNotFoundException causes absolutely no compiler error.

Nyeng Gyang wrote:(2.) It is a compile-time error if an exception of class E₁ is thrown in a try block and the corresponding catch block catches a subclass of E₁.

It is NOT a compile time error. I just gave you the code, wrapped in a class header this time, that you can compile without errors. It unambiguously shows that it is NOT a compile time error if I catch a checked exception that is a subclass of an exception type that can be thrown in the try-clause.

[Campbell Ritchie]

Nyeng Gyang wrote:. . . I will keep repeating myself . . .

I am afraid you are simply repeating the errors you made earlier.

. . . makes our discussion here . . . unproductive. . . . .

Agree. I can see no point in continuing to discuss the topic with you. Sorry.

[Nyeng Gyang]

Stephan van Hulst wrote:This is true, but the JLS gives a special exception from this rule if the exception to be caught is declared as Exception or Throwable in the catch-clause.

Stephan van Hulst wrote:This is not true. The compiler raises an error for ALL checked exception types, not just programmer defined exceptions, EXCEPT Exception and Throwable.

I have just confirmed that the foregoing remarks/claims you have made are true. This means that I was wrong in thinking that the compiler treats a checked exception of a checked exception class defined in the Java core API differently than it treats a checked exception of a programmer-defined checked exception class.

However, you have been using the wrong pieces of code to support your claim that the following claim I made is wrong: “It is a compile-time error to throw an exception of class E in a try block and place an exception of a subclass of class E in the corresponding catch block.” For the mpteenth time, I provide the following code as the correct code to use to demonstrate that this claim I have made is wrong:

import java.io.*;
public class ThrowingExceptions
{
   public static void throwIOException()
   {     
      try
      {
         throw new IOException();
      }
      catch(FileNotFoundException e)
      {
      }
   }   
}

The compiler reports the following error for the foregoing code:

ThrowingExceptions.java:8: error: unreported exception IOException; must be caught or declared to be thrown
         throw new IOException();
         ^
1 error

I would like to know why you disagree with me that the code I have provided above, rather than the one you provided (with the method both handling and declaring the exception) is the correct piece of code to use to support your claim that the claim I made is wrong.

The accuracy of this claim that I have made is the reason why my correction of the JLS quote is in order. I am glad that we should be making some progress in this discussion, since we have successfully addressed one of the issues discussed and only the other issue now remains. (The issue we have successfully addressed is my wrong thinking, as I have already explained at the beginning of this post, while the remaining issue is what I believe I have demonstrated to be a small discrepancy between a JLS "instruction" and a compiler action, which should be faithful to this JLS "instruction".)

[Stephan van Hulst]

The code you wrote does not demonstrate that it is a compiler error to catch a subtype of an exception that can be thrown from a try-statement. It demonstrates that it is a compiler error to have uncaught checked exceptions that are not reported using a throws declaration. The compiler error you get says you didn't catch IOException and you didn't report IOException. The compiler says nothing about FileNotFoundException.

The reason for the particular error you are getting is completely unrelated to your original question and to the part of the JLS that Campbell quoted. The compiler error you are getting is covered by the following part of the JLS:

Java Language Specification wrote:It is a compile-time error if a method or constructor body can throw some exception class E when E is a checked exception class and E is not a subclass of some class declared in the throws clause of the method or constructor.

https://docs.oracle.com/javase/specs/jls/se11/html/jls-11.html#jls-11.2.3


The code that I wrote demonstrates that it is NOT a compiler error to catch a subtype of an exception that can be thrown from a try-statement. My code throws IOException. I caught FileNotFoundException. The compiler didn't complain. QED.

As Campbell pointed out somewhere in this discussion, if something is not explicitly forbidden by the JLS, it is allowed.

[Nyeng Gyang]

Stephan van Hulst wrote:

Java Language Specification wrote:It is a compile-time error if a method or constructor body can throw some exception class E when E is a checked exception class and E is not a subclass of some class declared in the throws clause of the method or constructor.

It is not going to be useful, to this discussion, for me to address the foregoing quote you have provided and this is because it has no bearing, at all, in supporting your claim that the claim I made, and which has become the subject of some debate here, is wrong (again, this claim of mine is as follows: “It is a compile-time error to throw an exception of class E in a try block and place an exception of a subclass of class E in the corresponding catch block”). Responding to the JLS quote above will only muddy the waters for our discussion here.

I will provide two pieces of code and will use them to explain how my claim, with which you disagree, is the reason why the first piece of code successfully compiles, but the second piece of code does not.

Consider the following code:

import java.io.*;
public class ThrowingExceptions
{
   public static void throwIOException() throws IOException
   {     
      try
      {
         throw new IOException();
      }
      catch(FileNotFoundException e)
      {
      }
   }   
}

The following points are true for the code above:

(1.) The try block throws a checked exception that is of a superclass of the class of the checked exception attempted to be caught in the corresponding catch block.

(2.) It is illegal (i.e., a compile-time error) for a programmer to handle a checked exception in the manner described in point number 1 above.

(3.) Although the claim made in point number 2 above is accurate, the entire code nonetheless successfully compiles because the throwIOException() method code above declares the checked exception, which it did not adequately, correctly, legally handle inside the method’s body (as we will see shortly, in the next piece of code I provide, the inadequate, incorrect, illegal handling of the checked exception thrown by the code inside the body of the throwIOException() method becomes evident, as the compiler correctly reports).

Consider the following code and the compile-time error reported when the code gets compiled:

import java.io.*;
public class ThrowingExceptions
{
   public static void throwIOException()
   {     
      try
      {
         throw new IOException();
      }
      catch(FileNotFoundException e)
      {
      }
   }   
}

The compiler reports the following error for the second piece of code above:

ThrowingExceptions.java:8: error: unreported exception IOException; must be caught or declared to be thrown
         throw new IOException();
         ^
1 error

The following points are true for the second piece of code above and the error the compiler reports for the code:

(1.) Points numbers 1 and 2, which I have claimed are factual for the first piece of code above, are also true for the second piece of code above.

(2.) Because point number 1 above is accurate, as far as the compiler is concerned, the code inside the body of the throwIOException() method inadequately, incorrectly, illegally handles the checked exception thrown by the code and the compiler reports an error because the code does not declare the exception that it inadequately, incorrectly, illegally handled.

(3.) The error reported by the compiler demonstrates that, as far as it is concerned, the exception thrown inside the body of the throwIOException() method has neither been handled nor declared and this is true even though the code inside the method's body provides a catch block for handling the IOException that is thrown in the try block. Afterall, handling an exception, by simply providing a catch block, doesn’t mean that such exception handling is adequate, correct, legal. Inadequately, incorrectly, illegally handling a checked exception is as good as not actually handling it at all, even if the programmer implements try and catch blocks, and this is the reason why the compiler reports the particular error that it does for the second piece of code above.

Once again, for the umpteenth time, the second piece of code that I have provided above, rather than any of the several that you have provided so far, is the correct code to use to support your claim that my claim, with which you disagree, is wrong.