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

[Paul Clapham]

Nyeng Gyang wrote: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”).

That rule appears to be supported by your examples. So far so good. But then I tried versions which, instead of FileNotFoundException, used ArithmeticException in the catch block. The behaviour was the same in both cases -- but notice that ArithmeticException is not a subclass of IOException. So you should propose another rule for this situation, no? Because the rule you proposed doesn't cover it.

And then I tried versions which, instead of catching any exception at all, simply had an empty finally block. Again, same behaviour. So you need a third rule, no?

I'd say no. The rule "If the try block can throw an exception of class E, then either the corresponding catch blocks must catch all exceptions which are instances of type E or the containing method must declare class E to be thrown" is a lot simpler and it covers all cases instead of a subset of cases which your examples describe. (I'm sure that Stephan can clean up my crude rule-writing to make it more like the JLS. Or more likely a cleaned-up version of that rule has already appeared earlier in the thread.)

[Stephan van Hulst]

Nyeng Gyang, there is no point in me discussing this topic any more. You have shown that you have no true wish in understanding the JLS, illustrated by your indifferent dismissal of a very simple language rule that tells you exactly why your code is wrong.

According to you, not only are Campbell and I wrong, but the JLS itself is wrong, the very thing that defines the Java language.

I have lost interest in this topic. I hope you manage to come up with a comprehensive set of rules that will work for you, even if they are not really how Java works. Good luck.

[Nyeng Gyang]

Paul Clapham wrote:That rule appears to be supported by your examples. So far so good.

True. There is definitely no doubt that the correct code to use, to determine the accuracy of that rule, is the code I have been insisting should be used, rather than any of the several that Stephan kept providing. There can be no doubt that the reason, why the compiler reports an error when the throwIOException() method does not declare the checked exception thrown in its body, is because the code implementing the method illegally, inadequately, incorrectly handles this checked exception. This compiler action is congruent with the rule, which I have been claiming is correct all this time.

Yes, you are right that my provided rule does not cover unchecked exceptions (e.g., the ArithmeticException, which you gave an example of). However, I assumed that, since we were talking about checked exceptions (and definitely not unchecked exceptions), everyone would read my rule as implying only checked exceptions. Just to be clear, let me restate that rule again as follows, only, this time, spelling out that I mean a checked exception alone: “It is a compile-time error to throw a checked exception of class E in a try block and place an exception of a subclass of class E in the corresponding catch block.”

In order to underscore the fact that my rule pertains to only checked exceptions (and not unchecked exceptions), note and recall that I provided that rule, in the first place, because I wanted to show that the following correction needs to be made to a JLS rule that Campbell quoted: “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₁ ....” (Obviously, my suggested correction is that the phrase with the strike-through needs to be removed.)

You have suggested that a scenario, in which a checked exception is attempted to be caught by a catch block when the corresponding try block is empty, should be incorporated into the rule I provided. As per this suggestion that you have made, kindly note that this scenario is not intrinsically, fundamentally related to the scenario covered by the rule. I believe that the JLS should already have a rule that covers this scenario that you have suggested should be incorporated into the rule that I have provided, and I say this because the compiler, which should faithfully implement all JLS "instructions," reports the following error when I tried to compile code that creates the scenario:

TestExceptions.java:8: error: exception ActivationException is never thrown in body of corresponding try statement
      catch(java.rmi.activation.ActivationException e)
      ^
1 error

The foregoing error was reported after I compiled the following code:

public class TestExceptions
{
   public void method1()
   {
      try
      {
      }
      catch(java.rmi.activation.ActivationException e)
      {
      }
   }  
}

Paul Clapham wrote:The rule "If the try block can throw an exception of class E, then either the corresponding catch blocks must catch all exceptions which are instances of type E or the containing method must declare class E to be thrown" ...

The last part, of the foregoing rule that you have furnished here (which pertains to declaring the exception by the method), merely repeats a rule that I believe the JLS would already stipulate. Consequently, rewording my provided rule, as you have suggested here, would be redundant/superfluous (since the JLS should already have the "handle or declare checked exceptions" rule). There is no need to add a rule to the JLS, when the JLS already covers this rule.

[Nyeng Gyang]

Stephan van Hulst wrote:You have shown that you have no true wish in understanding the JLS, illustrated by your indifferent dismissal of a very simple language rule that tells you exactly why your code is wrong.

You and Campbell have performed the praiseworthy, commendable and thankworthy task of bringing my attention to a JLS rule (provided by Campbell) that answers the question I asked in my initial post, which started all the discussion that has ensued from this post and question. After writing and compiling code to ensure that the compiler action is congruent with this JLS rule, I eventually noticed that the rule actually does answer my question, and I clearly, unambiguously let everyone know this.

Stephan van Hulst wrote:According to you, not only are Campbell and I wrong, but the JLS itself is wrong, the very thing that defines the Java language.

Nope, Stephan. The only thing that I have said, which comes close to what you claim in the foregoing remark that you have furnished here, is that the JLS rule Campbell furnished needs the (albeit small, but important and non-trivial) correction that I have suggested.

[Paul Clapham]

Nyeng Gyang wrote:The only thing that I have said, which comes close to what you claim in the foregoing remark that you have furnished here, is that the JLS rule Campbell furnished needs the (albeit small, but important and non-trivial) correction that I have suggested.

No, your rule only covers part of what the JLS covers. Recall that your rule doesn't cover the situation where there's no catch block. And if you're claiming that your rule is a correction to the rule in the JLS then you're wasting your time with that claim. You can post on as many forums as you like but everybody is going to write you off as a crank.

[Nyeng Gyang]

Paul Clapham wrote:No, your rule only covers part of what the JLS covers.

Since everyone seems to be having trouble with my claim that my rule's correctness necessarily implies that my suggested correction, to the JLS rule in question, is in order or appropriate, I will adopt a different approach (which I employ shortly).

Paul Clapham wrote:Recall that your rule doesn't cover the situation where there's no catch block.

If you did not understand my explanation, in my previous reply to you, why I reject your suggestion that I incorporate the empty try block scenario into my rule then I will have to say that it is pointless for me to continue explaining why this suggestion you have made is moot to my rule and superfluous to the JLS.

Paul Clapham wrote:And if you're claiming that your rule is a correction to the rule in the JLS then you're wasting your time with that claim.

Once you have truly demonstrated that either or both of the following are wrong, I will immediately accept that this remark you have made is accurate: (1) My rule (2) The correction I have suggested needs to be made to the JLS rule. I have no problem conceding that I am wrong, when proof/evidence is provided to demonstrate that I am wrong. However, if such proof/evidence is not provided to demonstrate an allegation that I am wrong, but only an idle, lazy such allegation is advanced alone, it is the person making such baseless allegation that would be wasting their time, not me.

Paul Clapham wrote:You can post on as many forums as you like but everybody is going to write you off as a crank.

Anyone, who refuses and/or fails to demonstrate that my rule and suggested correction to the JLS rule are wrong, and would rather write me off as a crank, simply perpetrates fallacy ad hominem, by which they refuse/fail to address the issue being debated and would rather call me names.

[Paul Clapham]

Your rule is rather pointless, since it includes the assumption that the try statement is accompanied by exactly one catch statement. I mean, yeah, in that particular situation it repeats what the JLS already says, and so it's a correct rule, but that's about all. It's really not worth arguing about, in my opinion.

[Paul Clapham]

Nyeng Gyang wrote:(2) The correction I have suggested needs to be made to the JLS rule.

No corrections need to be made to the JLS. Remember that the "S" in "JLS" stands for "Specification". A specification defines how something (in this case the Java language) must work and therefore "correcting a specification" is a meaningless idea. If there are differences between what the JLS says and what your Java compiler does, then it's the compiler which is in error.

[Nyeng Gyang]

Paul Clapham wrote:Your rule is rather pointless, since it includes the assumption that the try statement is accompanied by exactly one catch statement.

Where you got the idea that my rule makes the assumption you have claimed, in your remark above that it does, simply beats me! This claim in the remark you have made is simply ridiculous and fraudulent. The claim is provably false, but it will amount to a waste of my precious time to provide the proof of its falsehood (which any open-minded, sincere person will have the capability of seeing, since this proof is very easy for such a person to see). Like I have already said, it is pointless for me to continue explaining why your suggestion, that I incorporate the empty try block scenario into my rule, is moot to the rule and superfluous to the JLS.

Paul Clapham wrote:Remember that the "S" in "JLS" stands for "Specification". A specification defines how something (in this case the Java language) must work and therefore "correcting a specification" is a meaningless idea. If there are differences between what the JLS says and what your Java compiler does, then it's the compiler which is in error.

I do agree with the foregoing remark you have made, in general, when a Java compiler action runs incongruent to a JLS rule that this compiler action should have faithfully implemented. However, there is a reason, which makes me think that the resolution, of the undeniable incongruence between (an, albeit, small though significant part of) this particular JLS rule and the corresponding Java compiler action, needs to be addressed by changing the JLS rule rather than changing the compiler action.

[Paul Clapham]

Nyeng Gyang wrote: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”).

Notice the word "the" near the end of your claim. That means that your rule only considers cases where there's exactly one catch block. That's what "the" means. And so it should, because if there's more than one catch block attached to a try block then the rule isn't true. Or at least, a revised rule which referred to "one of the corresponding catch blocks" wouldn't be true. Like so:

public void method likeSo {
  try {
    throw new Exception();
  } catch (IOException e) {
  } catch (Exception e) {
  }
}

No compile time error here.

I suspect that overlooking this case may have contributed to your idea that the Java compiler isn't a faithful implementation of the JLS.

[Nyeng Gyang]

Paul Clapham wrote:Notice the word "the" near the end of your claim. That means that your rule only considers cases where there's exactly one catch block. That's what "the" means. And so it should, because if there's more than one catch block attached to a try block then the rule isn't true. Or at least, a revised rule which referred to "one of the corresponding catch blocks" wouldn't be true.

There he goes again, shifting the goal post, by broaching both already existing issues and even a new one, which are moot to my rule. Whether it is your (old) suggestion of an empty try block or your (new) suggestion of multiple catch blocks, it is pointless for me to continue to explain why such suggestions are moot to my rule and/or even superfluous to the JLS.

Paul Clapham wrote:I suspect that overlooking this case may have contributed to your idea that the Java compiler isn't a faithful implementation of the JLS.

Another ridiculous and fraudulent, false remark.

[Paul Clapham]

You surely don't propose to modify the JLS by extra verbiage which only applies when a try block is followed by a single catch block?

I mean, I've already asserted that's exactly what you propose, but instead of bluster you really ought to either agree with that or improve your proposal.

[Nyeng Gyang]

Paul Clapham wrote:You surely don't propose to modify the JLS by extra verbiage which only applies when a try block is followed by a single catch block?

So, I am truly not sure whether this question has arisen out of your sincere, genuine misunderstanding of the correction I propose or a crafty attempt at fraud.

Paul Clapham wrote:I mean, I've already asserted that's exactly what you propose ...

The only part of this foregoing remark you have made, with which I agree, is that you have made an assertion and no more; an assertion that is either sincerely or maliciously wrong.

I have thought of employing yet another approach to demonstrate that your take on my suggested correction is wrong. However, until I am able to confirm that this your misunderstanding of the suggested correction is due to genuine, sincere misunderstanding, rather than deliberate crafty obfuscation, I fear that I will only waste my time making any such attempt at supporting and clarifying my claim that you have decidedly gotten my suggested correction wrong.

[Paul Clapham]

Nyeng Gyang wrote:I have thought of employing yet another approach to demonstrate that your take on my suggested correction is wrong. However, until I am able to confirm that this your misunderstanding of the suggested correction is due to genuine, sincere misunderstanding, rather than deliberate crafty obfuscation, I fear that I will only waste my time making any such attempt at supporting and clarifying my claim that you have decidedly gotten my suggested correction wrong.

This would be a welcome change. So far you have only been vigorously avoiding saying anything which would support your claim. Instead you have limited yourself to attacking people who would like to clarify it.

And indeed it's likely that my take on your claim is wrong. That's why I have repeatedly asked you to clarify. I have provided several examples; you have done nothing except to reply that your claim should be obvious. The examples were intended to explore the limits of your claim. In other words all of the examples I have provided, in your view, result in a compiler and your assertion is that the JLS says that is the correct behaviour. Your single example, however, is very similar to mine so it's your responsibility to explain what the differences are and how that's related to the JLS.

The other thing to take into account is that if your goal is to demonstrate that the JLS is incomplete and needs repairing, then demonstrating that I'm wrong is not what you want to do. That means nothing. Your goal should be to demonstrate that you are right. So far I have seen nothing like that. So, I look forward to seeing your clarifications.

[Nyeng Gyang]

Paul Clapham wrote:You surely don't propose to modify the JLS by extra verbiage which only applies when a try block is followed by a single catch block?

In the interest of avoiding digressions and obfuscations that you have persisted at, I will challenge you to demonstrate how the suggestion in the foregoing question, which you posed in a previous post, is not irrelevant and superfluous to my suggested correction to the JLS rule. I would rather we address the irrelevant and superfluous suggestion you make in this question you have asked than fully/adequately respond to the new falsehoods, digressions and obfuscations that you have added. I would rather we addressed one issue/question before proceeding to another.

Paul Clapham wrote:This would be a welcome change. So far you have only been vigorously avoiding saying anything which would support your claim. Instead you have limited yourself to attacking people who would like to clarify it.

This remark is simply a classic case/example of projection, by which you accuse me of attacking anyone when it was you who subtly alluded that I am a crank. That I challenge you to demonstrate how your multiple suggestions are not irrelevant and superfluous is not tantamount to me attacking you. Surely, you can see that this is true.

Paul Clapham wrote:And indeed it's likely that my take on your claim is wrong. That's why I have repeatedly asked you to clarify. I have provided several examples; you have done nothing except to reply that your claim should be obvious.

In response to your bizarre remark that the main point I have sought to convey is not clarified or obvious, I will refer you to the following remark I made in a previous post I made: "Once you have truly demonstrated that either or both of the following are wrong, I will immediately accept that this remark you have made is accurate: (1) My rule (2) The correction I have suggested needs to be made to the JLS rule." Please, just perform these two tasks and our very long and unnecessarily convoluted discussion here will come to and end, with my concession that I have wrongly claimed that the JLS rule needs to be corrected, as I have suggested. My asking you to do this should be a more straightforward approach than even the other one about which I broached in my previous post.

Paul Clapham wrote:The examples were intended to explore the limits of your claim. In other words all of the examples I have provided, in your view, result in a compiler and your assertion is that the JLS says that is the correct behaviour. Your single example, however, is very similar to mine so it's your responsibility to explain what the differences are and how that's related to the JLS.

I am simply not following the message you are communicating here.

Paul Clapham wrote:The other thing to take into account is that if your goal is to demonstrate that the JLS is incomplete and needs repairing, then demonstrating that I'm wrong is not what you want to do. That means nothing. Your goal should be to demonstrate that you are right. So far I have seen nothing like that. So, I look forward to seeing your clarifications.

You are right that my task here is not to demonstrate that you are wrong, but to demonstrate that I am right. However, your allusion that I am not performing this task, which we both agree that I should be performing, is provably false; the proof of this falsehood is my challenging you to demonstrate that my rule and suggested correction to the JLS rule are wrong and your circumvention of this challenge. Instead of pointedly addressing this challenge, you have persisted at providing digressions and obfuscations. (I assume that you accept that my challenging you to demonstrate that I am wrong is equivalent to my demonstrating that I am right; this is because your failure to win this challenge inexorably demonstrates that I am right; failing to demonstrate that my rule and suggested correction to the JLS rule are wrong is tantamount to a proof that the point I have sought to advance all this while is right. This equivalence is proof that the following remark you made is false or misleading, at best, and fraudulent, at worst: "So far I have seen nothing like that. So, I look forward to seeing your clarifications").

Speaking of your looking forward to seeing my clarifications, the only clarification that I will provide is my repeating my challenge that you demonstrate that my rule and suggested correction to the JLS rule are wrong.