-1

I want to "get around" the strict restrictions placed on methods by the throws clause. So I decided to subclass RuntimeException to make up a new, exempt exception of my own. Now I can throw it to my heart's content, because the throws clause that was annoying me does not need to include this new exception but the code is not working.

public class Cnf extends RuntimeException {
    public Cnf(){};
}
    
public class Example1 { 
    public static void main(String args[]) { 
        if(Class.forName("GeeksForGeeks")==null){
            throw new Cnf();
        else
            System.out.println("Hello");
        } 
    } 
}
xtratic
  • 4,600
  • 2
  • 14
  • 32
Anshul Gupta
  • 265
  • 2
  • 12

2 Answers2

2

Your problem is that Class.forName is the one that's throwing the exception.

Easiest, naive, solution to "get around" an exception in this way is to catch then re-throw the exception in a RuntimeException. This is much better than catching and ignoring the exception but I don't recommend this unless you are quite sure that checked exception will/must never occur. However, I do agree this is probably an ok way to handle the checked exceptions thrown by Class.forName since you're quite sure that classname will/must exist, and if it doesn't then you'll still get a clear exception at runtime just as if you dealt with the checked exceptions.

public static void main(String args[]) {
    Class<?> klass;
    try {
        klass = Class.forName("qualified.name.of.GeeksForGeeks");
    } catch (Exception e) {
        throw new RuntimeException(e);
    }
    // do something with your klass...
} 
xtratic
  • 4,600
  • 2
  • 14
  • 32
0

Let's jump straight to the real solution to your problem:

put throws Exception on your main method. Problem solved.

Now for your new fancy runtime exception: your method must either [A] catch, or [B] put in the 'throws' clause, unless it is a runtimeexception in which case you don't need do that - for all exceptions you either explicitly throw with the throw statement, OR for any method invocations you invoke, all exceptions listed on their throws line in the method signature.

The Class.forName call lists a bunch of checked exceptions. You have to handle them. Putting that call in an if doesn't change anything about that.

rzwitserloot
  • 85,357
  • 5
  • 51
  • 72
  • I want to "get around" the strict restrictions placed on methods by the throws clause – Anshul Gupta Jul 07 '20 at 14:11
  • You can't do that. As I said, add `throws Exception` to your main, that is the only way to end up with being allowed to invoke all sorts of methods without bothering to write catch clauses. – rzwitserloot Jul 07 '20 at 14:16
  • We can do that check this http://101.lv/learn/Java/ch17.htm. Check Q&A. – Anshul Gupta Jul 07 '20 at 14:27
  • @Anshul Gupta None of that link shows you how to 'get around'checked exceptions without actually catching them first, or declaring them in your throws clause. – rzwitserloot Jul 07 '20 at 16:27
  • For checked exceptions we need to write the throws clause in the method declaration. My question is how to get around it. – Anshul Gupta Jul 07 '20 at 16:58
  • @Anshul Gupta as I said.. __You can't do that.__ If you are writing your own exceptions, have them extend runtimeexception. If you're calling methods you didn't write, and that method throws checked exceptions, you have to either catch them, or update your method signature to throw them onwards, and you can't get around this. – rzwitserloot Jul 07 '20 at 17:02
  • Actually this is the question I am talking about- Is there any way to "get around" the strict restrictions placed on methods by the throws clause? – Anshul Gupta Jul 07 '20 at 17:23
  • use Kotlin, there you have only unchecked exceptions – P.J.Meisch Jul 07 '20 at 20:28