LBYL与Java中的EAFP？ [英] LBYL vs EAFP in Java?

问题描述

我最近在教自己的Python，并发现了代码执行之前关于错误检查的LBYL / EAFP成语。在Python中，似乎接受的风格是EAFP，它似乎与语言一起工作。

LBYL（ L ook B efore Y ou L eap ）：

  def safe_divide_1（x，y）：
如果y == 0：
打印检测到0分尝试
返回无
其他：
返回x / y 
  

EAFP（ strong> asier to A sk F 组织比 P ermission ）：

  def safe_divide_2（x，y）：
 try：
 return x / y 
除了ZeroDivisionError：
 printDivide-by -0尝试检测到
返回无
  

我的问题是这样：我从来没有听过使用EAFP作为主要数据验证结构，来自Java和C ++背景。 EAFP在Java中使用明智吗？还是有异常的开销太多？我知道在实际抛出异常时只有开销，所以我不确定为什么不使用更简单的EAFP方法。只是偏爱吗？

解决方案

个人而言，我认为这是由惯例支持的，EAFP从来不是一个好办法。
您可以将其视为等同于以下内容：

  if（o！= null）
 o.doSomething（）; 
 else 
 // handle 
  

而不是：

  try {
 o.doSomething（）
} 
 catch（NullPointerException npe）{
 / / handle 
} 
  

此外，请考虑以下内容：

  if（a！= null）
 if（b！= null）
 if（c！= null）
 a 。.getB（）GETC（）的doSomething（）; 
 else 
 // handle c null 
 else 
 // handle b null 
 else 
 //处理一个null 
  

这可能看起来不那么优雅（是的，这是一个粗略的例子 - 与我一起），但它给你更大的粒度处理错误，而不是将其全部包含在try-catch中以获取 NullPointerException ，然后尝试弄清楚它在哪里和为什么。

我看到它的方式EAFP不应该被使用，除了罕见的情况。此外，由于您提出了这个问题：是的，即使未抛出异常，try-catch块也会导致一些开销。

I was recently teaching myself Python and discovered the LBYL/EAFP idioms with regards to error checking before code execution. In Python, it seems the accepted style is EAFP, and it seems to work well with the language.

LBYL (Look Before You Leap):

def safe_divide_1(x, y):
    if y == 0:
        print "Divide-by-0 attempt detected"
        return None
    else:
        return x/y

EAFP (it's Easier to Ask Forgiveness than Permission):

def safe_divide_2(x, y):
    try:
        return x/y
    except ZeroDivisionError:  
        print "Divide-by-0 attempt detected"
        return None

My question is this: I had never even heard of using EAFP as the primary data validation construct, coming from a Java and C++ background. Is EAFP something that is wise to use in Java? Or is there too much overhead from exceptions? I know that there is only overhead when an exception is actually thrown, so I'm unsure as to why the simpler method of EAFP is not used. Is it just preference?

解决方案

Personally, and I think this is backed up by convention, EAFP is never a good way to go. You can look at it as an equivalent to the following:

if (o != null)
    o.doSomething();
else
    // handle

as opposed to:

try {
    o.doSomething()
}
catch (NullPointerException npe) { 
    // handle
}

Moreover, consider the following:

if (a != null)
    if (b != null)
        if (c != null)
            a.getB().getC().doSomething();
        else
            // handle c null
    else
        // handle b null
else
    // handle a null

This may look a lot less elegant (and yes this is a crude example - bear with me), but it gives you much greater granularity in handling the error, as opposed to wrapping it all in a try-catch to get that NullPointerException, and then try to figure out where and why you got it.

The way I see it EAFP should never be used, except for rare situations. Also, since you raised the issue: yes, the try-catch block does incur some overhead even if the exception is not thrown.

这篇关于LBYL与Java中的EAFP？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！