识别罪魁祸首的记录 - 编码实践

Question

方法链接好吗？

我并不反对经常使用方法链的函数式编程，而是反对一种从众心态，即人们盲目地追逐新事物。

这个例子，如果我正在使用流编程处理项目列表，并且需要找出导致抛出NullPointerException的确切行。

private void test() {
    List<User> aList = new ArrayList<>();
    // fill aList with some data
    aList.stream().forEach(x -> doSomethingMeaningFul(x.getAddress()));
}

private void doSomethingMeaningFul(Address x)   {
     // Do something
}

因此，在上面的示例中，如果list中的任何对象为null，则在调用< code>x.getAddress()时，它将导致< code > NullPointerException 并退出，而没有给我们一个钩子来标识有此问题的用户记录。

我可能错过了在流编程中提供此功能的东西，任何帮助都是值得赞赏的。

编辑1：NPE只是一个例子，但还可能发生其他几个运行时异常。编写筛选器实质上意味着根据我正在执行的操作检查每个 RTE 条件。检查每次手术都会变得很痛苦。

为了更好地理解我的意思，下面是使用旧方法的代码段；我找不到任何与流/函数编程方法等价的方法。

List<User> aList = new ArrayList<>();
// Fill list with some data
int counter = 0;
User u = null;

try {
      for (;counter < aList.size(); counter++) {
          u = aList.get(counter);
          u.doSomething();
          int result = u.getX() / u.getY();
      }
} catch(Exception e)  {
  System.out.println("Error processing at index:" + counter + " with User record:" + u);
  System.out.println("Exception:" + e);
}

This will be a boon during the maintenance phase(longest phase) pointing exact data related issues which are difficult to reproduce.
**Benefits:**
- Find exact index causing issue, pointing to data
- Any RTE is recorded and analyzed against the user record
- Smaller stacktrace to look at

Answer 1

在test()函数中，您创建了一个emptylist 列表

在上面做每一件事。首先添加一些元素到

a列表

如果要处理空值，可以添加 .filter（x-

下面是代码

private void test() {
        List<User> aList = new ArrayList<>();

        aList.stream().filter(x-> x != null).forEach(x -> doSomethingMeaningFul(x.getAddress()));
}

private void doSomethingMeaningFul(Address x)   {
        // Do something
}

Answer 2

这有几个方面。

1） 空值

最好避免检查空值的问题，不要给空值赋值。这适用于你是否在做函数式编程。不幸的是，许多库代码确实暴露了空返回值的可能性，但是尝试通过在一个地方处理它来限制这种可能性。

不管您是否在做FP，如果您在调用自己的方法时不必编写null检查，您会发现您会少得多的沮丧，因为您自己的方法永远不会返回null。

对于可能为空的变量，另一种方法是使用Java 8的< code>Optional类。

而不是：

public String myMethod(int i) {
     if(i>0) {
          return "Hello";
     } else {
          return null;
     }
}

做:

public Optional<String> myMethod(int i) {
     if(i>0) {
          return Optional.of("Hello");
     } else {
          return Optional.empty();
}

查看< code>Optional Javadoc，了解这如何迫使调用者考虑< code>Optional.empty()响应的可能性。

作为“null表示不存在”和“可选。empty（）表示不存在”，您可以使用可选。ofNullable（val），当val==null时返回为空。但请记住，是可选的。empty（）和可选。of（null）是不同的值。

2）例外

确实，在流处理程序中引发异常效果不佳。异常不是一个非常FP友好的机制。FP友好的替代方案是Aose--它不是Java的标准部分，但很容易自己编写或在第三方库中找到：在Java 8中是否有与Scala的Aly等效的Aly？

public Either<Exception, Result> meaningfulMethod(Value val) {
    try {
       return Either.right(methodThatMightThrow(val));
    } catch (Exception e) {
       return Either.left(e);
    }
}

…然后：

List<Either<Exception, Result>> results = listOfValues.stream().map(meaningfulMethod).collect(Collectors.toList());

3） 索引

当使用由< code>List构成的流时，您想知道流元素的索引？参见Java 8中有没有简洁的方法迭代带索引的流？

Answer 3

方法链接好吗？

像往常一样，简单的答案是：视情况而定。

当您

• 知道你在做什么
• 非常确定元素永远不会为空，因此在这样的构造中NPE的机会是（接近）0
• 呼叫的链接提高了易读性

然后当然，链式调用。

如果上述任何一项标准没有得到明确满足，则考虑不这样做。

在任何情况下，在新行上分发您的方法调用可能会有所帮助。当您这样做时，像IntelliJ这样的工具实际上会为您提供每行的高级类型信息（好吧，并不总是，请参阅我自己的问题；）

从另一个角度来看：对于编译器来说，链调用并不重要。这真的只对人类重要。为了可读性或在调试期间。