JVM:如何定义java可执行文件的退出代码?

mst*_*rap 4 java jvm

我正在寻找java可执行文件的可能退出代码的定义:

(如何)我可以判断退出代码是执行Java进程还是VM本身?

示例:在Windows上,java -badoption返回1; java MainMain作为一个有效的类可以返回1为好.

我可以使用任何VM选项来使退出代码更有意义吗?例如,要区分两种类型的退出代码?

如果我知道退出代码不是来自我的Java进程(只返回0),那么非零退出代码是什么意思?

在Windows上,我经常看到-11.由于这些是通过自动错误报告工具报告的,我看不到任何错误消息.我只有退出代码,需要解释它.

退出代码是否依赖于平台?

Chr*_*jer 6

退出代码的含义(一般)

ISO/IEC 9899(编程语言:C),ISO/IEC 9945(IEEE 1003,POSIX)

没有为Java/JVM专门定义的内容.这些退出代码的含义由ISO/IEC 9899定义的(编程语言:C,例如7.20.4.3所述exit的功能ISO/IEC 9899:TC3),ISO/IEC 9945(IEEE 1003,POSIX)和类似的规格,并它总是这样:

  • 0表示成功
  • 任何其他值都意味着失败

这是用来通过壳环境(sh,bash,cmd.exe,make等等,等等),以确定程序是否成功退出(0)或出现错误(不为0).

强烈建议仅使用0表示成功.使用0以外的值进行成功的程序会给shell脚本,Makefile等的作者带来麻烦.

由单个程序来定义不同故障值的附加语义.但是,我认为-1这不是一个好主意.最好的事情是使用EXIT_SUCCESSEXIT_FAILURE,不过,从这些定义<stdlib.h>在Java中没有相应的同行.ISO/IEC 9899:2011不介绍如何EXIT_FAILUREEXIT_SUCCESS应该被定义.但是,它将0定义为具有相同的语义EXIT_SUCCESS,并且我不知道除了以下内容之外的任何其他系统,因此这是Java程序员可以假设的最好的事情:

#define EXIT_SUCCESS 0
#define EXIT_FAILURE 1
Run Code Online (Sandbox Code Playgroud)

因此,如果区分不同类型的故障很重要,我会使用0表示成功,1表示失败,值不同于1.grep命令就是一个很好的例子.从其手册页(GNU grep):

退出状态如果找到选定的行,则退出状态为0,如果未找到,则退出状态为1.如果发生错误,则退出状态为2.(注意:POSIX错误处理代码应检查"2"或更大.)

我不会使用-1,因为它设置所有位,并且根据环境,-1实际上可能会意外地生成额外的虚假信息,例如声称信号被提升和相似.实际上,为了便携,退出代码应该在范围内[0..127],除非你真的真的知道你在做什么.例如,在大多数POSIX系统上,退出代码将被截断为8位,退出代码高于127的语义是退出是由信号引起的.

BSD

BSD已尝试提供更多退出代码,可在/usr/include/sysexits.h(手册页)中找到.它们是这样的:

  • 64:命令行使用错误
  • 65:数据格式错误
  • 66:无法打开输入
  • 67:收件人未知
  • 68:主机名未知
  • 69:服务不可用
  • 70:内部软件错误
  • 71:系统错误(即不能分叉)
  • 72:缺少关键操作系统文件
  • 73:无法创建(用户)输出文件
  • 74:输入/输出错误
  • 75:临时失败; 邀请用户重试
  • 76:协议中的远程错误
  • 77:许可被拒绝
  • 78:配置错误

在没有任何其他有意义的标准的情况下,我认为我们能做的最好的事情就是使用它们.

解释JVM生成的退出值

POSIX上的JVM

在UNIX上,您可以通过从退出值中屏蔽低7位(减去128)来获取信号,在大多数shell中可以使用它来查询$?.

  • SIGTERM - > VM: 143 SIGTERM
  • SIGSEGV- > VM :( 134 SIGABRT因为VM处理SIGSEGV以写入hs_err文件然后调用abort()).

与"正常"计划的比较:

  • SIGSEGV - >前卫: 139 SIGSEGV

没有为JVM显式指定此行为,它只是POSIX环境中程序的正常预期行为.即使是SIGABRT代替SIGSEGV或多或少的预期,考虑到JVM要处理SIGSEGV自身,写一个更具体的崩溃转储比正常核心文件.

Windows上的JVM

去做