在一个Unix环境，在这种划分被零是
signal通过主导
SIGFPE，JVM将已安装的陷阱的信号处理程序
SIGFPE，进而
throwS上的
ArithmeticException。如果您对内部结构感兴趣，请参见例如
mansignal
我认为OP提出的要求是基于这样一个事实，即直到/除非有
SIGFPE处理程序到位，大多数进程都会在接收到此信号时采取默认操作，即终止操作。因此，例如一个C程序
int main (int argc, char** argv) { int n = 5 / 0; }…即使编译，也会被默认的
SIGFPE→
SIG_DFL操作杀死。JVM的处理程序改为发出（
catch能力），
RuntimeException以便可以以本机似的方式处理这些异常。
正如其他一些人指出的那样，并且仅仅是为了完整性，事实上
SIGFPE，内核生成的代码通常是根据处理器本身的特殊中断来映射的。因此，“管道”就像
- CPU错误陷阱中断→内核中断处理程序
SIGFPE
SIG_DFL
→→进程死亡
要么
- CPU错误陷阱中断→内核中断处理程序→
SIGFPE
JVM中的处理程序→RuntimeException
ArithmeticException
用户代码中
在非Unix平台上，处理类似。
