捕获异常只是懒惰的错误检查?

Mik*_*ike -1 java exception-handling try-catch

我确定我会为此感到沮丧...但我来自一个没有try/ catch块的语言,而且我正在学习Java异常捕获,我很难看到它不是只是一个懒惰的验证版本.我见过几个例子:

String Box [] = {"Book", "Pen", "Pencil"};
while(i<4)
{
    try
    {
        System.out.println(Box[i]);     
    }
    catch(ArrayIndexOutOfBoundsException e)
    {
        System.out.println("Subscript Problem " + e);
        i++;
    }
Run Code Online (Sandbox Code Playgroud)

和:

int y = 0;
int x = 1;
// try block to "SEE" if an exception occurs
try
{
    int z = x/y;
    System.out.println("after division");
} 
catch (ArithmeticException ae) 
{
    System.out.println(" attempt to divide by 0");
}
Run Code Online (Sandbox Code Playgroud)

这些显然是非常基本的例子......但IMO要么是捕捉错误的可怕例子,要么没有充分的理由去做.在示例一中,如果我们循环元素的数量,Box我们不需要检查越界索引.在示例二中,如果我们检查0的除数,我们不需要检查它ArithmeticException.

是否有一个很好的例子或理由为什么使用try/ catchblocks比仅仅是旧时尚变量验证更好?还是仅仅是"Java"方式?

Mar*_*nik 6

这将是一个没有例外的语言的例子:

if (!rename(file1, tmpName))
  if (!rename(file2, file1))
     if (!rename(tmpName, file2))
        return 0;
return -1;
Run Code Online (Sandbox Code Playgroud)

另请注意,没有详细说明究竟出了什么问题.

与Java比较:

try {
   rename(file1, tmpName);
   rename(file2, file1);
   rename(tmpFile, file2);
   return true;
}
catch (IOException e) {
   e.printStackTrace();
   return false;
}
Run Code Online (Sandbox Code Playgroud)

如果rename在异常消息中正确存储源名称和目标名称,我们将确切地知道它变坏的地方.

总而言之,异常机制的优点包括:

  • 允许你声明一个代码块,它必须作为一个整体成功,任何错误都得到平等对待;
  • 允许您将所有错误处理委托给应用程序中的单个点,即所谓的异常屏障 ;
  • 异常对象存储重要的调试信息.

例外是一个巨大的胜利,所有现代语言都有它们.