Skip to main content

Java back in the 1930s.

Posted by unoinpiu on May 15, 2009 at 5:48 AM PDT

Consider the following interface:

public interface X
{
   public void doSomething() 
}

and two implementations:

public class Good implements X
{
   public void doSomething() { ; } 	
}
public class Bad implements X
{
   public void doSomething() { throw new RuntimeException(""); } 	
} 

Let's have a convenience class ExcpnChecker with just one static method to check whether a given implementation of X is going to throw an exception or not.

public final class ExcpnChecker
{
   public static boolean isThrowingException(X x) 
   { 
      try
      {
         x.doSomething();
         return false; 
      }
      catch (Exception e)
      {
         return true; 
      }
   }
}

such that:

ExcpnChecker.isThrowingException(new Good()); // returns false
ExcpnChecker.isThrowingException(new Bad());  // returns true

Consider now a third implementation of the X interface:

public class Pun implements X
{
   public void doSomething()
   { 
      if (ExcpnChecker.isThrowingException(this)) return;
      else throw new RuntimeException();       
   }  
}

can you tell what we get from

ExcpnChecker.isThrowingException(new Pun()); 

Now, think...


To see a short explaination highlight (select) the text below:


Although the method isThrowingException seems correct, it is not.
For example, it is not capable to handle the case of some X implementations which refer to itself, as we have shown with Pun.
Moreover, it is not able to handle other cases such as this:

public class Forever implements X
{
   public void doSomething() { while(true) { ; } }
}

If I were to pass an instance of Forever to 'isThrowingException'
I would expect it to return false instead of looping for ever.

You can try very hard to fix the 'isThrowingException' but you won't succeed.

The method "isThrowingException for an arbitrary X implementation" is not computable.

see:


http://en.wikipedia.org/wiki/Halting_problem


http://en.wikipedia.org/wiki/G%C3%B6del's_incompleteness_theorems

Related Topics >>

Comments

@kebernet: Not quite right. ExcpnChecker will throw a StackOverflowError and since we only catch Exception it will terminate abruptly. (This was deliberate)
Attempting to fix it by catching "Throwable" would return 'true' as you say but that would be incorrect since Pun's code says: "if I throw an exception I return peacefully, If don't throw an exception let me throw one"
The problem is that such a program can not be coded. The reason people might think they can write it is based on the assumption (wrong) that ExcpnChecker can be written.

Actually, I think you are missing something here. Because Pun is, in effect, recursive, ExcpnChecker.isThrowingException(new Pun()); will return false, because you will get a StackOverflowException after some amount of time at which point, the parent method would get "true" and therefore return without error and all the calls farther up the tree would get no exception, making the top level call return false. You are correct about the Forever implementation, however.

You aren't saying this is specific to Java, are you?