在一个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平台上,处理类似。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)