In Java, both checked exception and unchecked exception can be thrown explicitly, i.e, by a throw statement. Besides, unchecked exceptions like ArithmeticException and OutOfMemoryError can be triggered without any explicit throw statement like this:
public static void throwArithmeticException() {
    int i = 1;
    int j = i / 0;
}
public static void throwOutOfMemoryError() {
    List<Object> list = new ArrayList<>();
    while(true) {
        list.add(new Object());
    }
}
So my question is, is there any way to trigger an checked Exception, like IOException, implicitly, i.e. not using any throw statement?
                        
You can do it, but you shouldn't1.
I assume that you are talking about the
athrowbytecode instruction. (And that you really asking if you can trigger an exception from your code without using athrowstatement.)There are (at least) two ways for an application to throw an arbitrary Java exception (checked or unchecked) that don't involve an explicit
athrowinstruction.You can call
Unsafe.throwException(Throwable).In native code, you can call the
ThroworThrowNewfunctions in the JNI API.In both cases, you can circumvent the Java (compile time and verifier) checks that are intended to ensure that checked exceptions are always declared (via a
throwsclause) or handled.Note using
Unsafeor native code means that your code is not Pure Java. It won't be portable. Furthermore it is easy to do things that will make a JVM unstable. JVM crashes are not unusual.In addition, the JVM will itself throw exceptions without an
athrowinstruction. For example, if you try to usenew FileInputStreamto open a file that doesn't exist andFileNotFoundExceptionis thrown, it is being throw from native code, not from compiled Java code.It follows that your application can use this mechanism to implicitly throw many checked and unchecked exceptions; e.g. by deliberately trying to open a non-existent file. However, the method signature for
readdeclares that it may throwIOException, so the compiler knows about this ... from the perspective of the checked exception rules.1 - And if you application design requires this kind of craziness, you would be advised to come up with an alternative. It is a bad idea to try to fight Java's checked exception rules. If you dislike them so much that you are contemplating this, you should pick a different programming language.