Java: How to throw a custom Runtime Exception without using a throw statement?

Question

Say, I want to prevent a divide by 3 anywhere within my current package. Usual procedure is to make an Exception subclass:

class NoDivbyThreeException extends RuntimeException {
    public NoDivbyThreeException (String msg) {
        super(msg);
    }
}

and then throw it where required:

class CustomExceptionDemo {
    public static void main(String[] args) {
        int numr = 5;
        int denr = 3;
        try {
            if (denr==3) throw new NoDivbyThreeException("Div by 3 not allowed");
            else System.out.println("Result: " + numr/denr);
        }
        catch (NoDivbyThreeException e) {
            System.out.println(e);
        }
     }
}

But what I want is that JVM should prevent a division by 3 anywhere inside this package without my explicit stating of the throw statement inside main(). In other words, the way JVM prevents a divide by zero by throwing exception automatically whenever it encounters such scenario, I want my program to do the same whenever it encounters a divide by 3 situation inside a package.

Is this possible? If not, please elaborate why. That will help to clear my concepts.

Answer 1

I don't think this is trivially possible.

You want 5 / 3 to throw an exception, right? The same as 5 / 0? According to this answer, "In an Unix environment, in which division-by-zero is signalled via SIGFPE, the JVM will have installed a signal handler which traps the SIGFPE and in turn throws an ArithmeticException."

In other words, the error caused by 5 / 0 doesn't start with the JVM, it starts with the CPU or kernel, outside of Java. You can't get the CPU or kernel to throw an exception when dividing by 3, and you can't override the behaviour of division in Java.

See also

• How does Java handle division by zero?
• SIGFPE
• idiv JVM instruction set code

Answer 2

There's no way to throw an Exception without explicitly throwing it. Except for some internal Exceptions, like division by 0, which are handled by the JVM. These include NullPointerException, if not thrown by an explicit throw-statement, division by 0 and a few other errors. But these exceptions are actually created by receiving an error from the underlying platform. E.g. in case of division-by-0, the error is already generated by the CPU.

So unless your code somehow creates an error in the underlying platform, you'll have to create the error yourself. Anything else would require the JVM to be highly mutable, which wouldn't make much sense due to inconsistent behavior, which is not desirable and results in an extreme security-risk. As an example for why it's undesirable to make the JVM muteable:
Consider your example:

We could have three options to handle this (none exists, AFAIK):

• alter the code in the compiler, to throw an exception, if any division by three (might) occur. Disadvantage: bloats code
• alter the behavior of the JVM: even more undesirable. Consider a library that throws an exception for division by 3. Now you want to use the library in your code. But you expect normal arithmetic behavior and get some strange error when dividing by 3.
• add a header to the library that describes expected behavior of the JVM. Comparable to the first option, only the load is moved from compilation and memory to the runtime and startup/on the run compilation.

Answer 3

To do that, you have to modify java.lang.ArithmeticException , which I believe the authorities will not let you do if they know you want to make ArithmeticException for divide by 3 :) .