Question

我正在使用jSerialComm库与SerialPort进行通信。我编写了一个SerialDataListener来读取带有重写的serialEvent方法的字节，如下所示：

@Override
public void serialEvent(SerialPortEvent event) {
    if (event.getEventType() != SerialPort.LISTENING_EVENT_DATA_AVAILABLE) return;
    int numBytesAvailable = serialPort.bytesAvailable();
    if (numBytesAvailable < 0) {
        logger.error("Port is not open.. returning without any action");
        return;
    }
    byte[] newData = new byte[numBytesAvailable];
    int readData = serialPort.readBytes(newData, numBytesAvailable);
    for (int i = 0; i < numBytesAvailable; i++) {
        byte b = newData[i];
        logger.info("Starting new response");
        response = new Response();
        response.addByte(b);
    }
}

现在，如果我确实收到数据并且后续代码以某种方式进入NUllPointerException（一个例子是调用响应的构造函数并抛出NPE），那么SerialPort已在库的SerialPort类中编程为

停止聆听
吞下例外
作为1和2的结果，不能再处理到达SerialPort的数据。既没有公开的API来查看侦听器是否已停止并重新启动它。我不能采取任何行动，比如重新打开SerialPort。

这是一段代码：

//Line 895 of the class SerialPort) (from dependency:  com.fazecast:jSerialComm:1.3.11).

while (isListening && isOpened) { try { waitForSerialEvent(); } catch (NullPointerException e) { isListening = false; } }

以下是问题：

为什么吞下异常并在库内停止监听？有没有设计理由？
SerialPort类本身是final，因此编写我自己的类实现来替换swallow是不可能的。我该怎么办？除了这个问题，jSerialComm似乎很好地满足了大多数其他用例，所以我可能不会很快从它迁移。
一种方法是亲自抓住它并进行处理。但除非Q1的答案清楚，否则我不想这样做。我试图调查，但没有找到任何禁用听力的实际原因，也没有发布异常。
为什么只是NPE，其他例外也可能出现。那么至少，我将不得不自己处理异常。我的处理程序的这种方法是否正确呢？

TIA 拉胡

Answer 1

1）为什么吞下异常并在库内停止监听？有任何设计原因吗？

您需要询问代码的作者。

但是，它似乎是故意的，因为waitForSerialEvent被声明为throws NullPointerException。

如果我是你，我会深入研究NPE的投掷位置以及原因。修改代码以打印堆栈跟踪，而不是完全压缩异常。它可能是一种“黑客”解决方法，或者可能有合理的理由这样做。

如果我们假设客户端的侦听器代码可以抛出NPE，那么在我看来，事件线程假设所有NPE都可以被压扁是错误的。

但是看看代码，我还可以看到NPE被故意抛出的地方（显然）发出错误信号;例如在read中的SerialPortInputStream方法中。所以我不清楚NPE应该被压扁。

2）SerialPort类本身是最终的，因此编写我自己的类实现来替换swallow是不可能的。我该怎么办？

代码在GitHub上，因此可以分叉存储库，开发补丁并提交拉取请求。

4）为什么只是NPE，其他例外也可能出现。那么至少，我将不得不自己处理异常。我的处理程序的这种方法是否正确呢？

好问题。

但实际上，所有这些问题最好都是针对代码的作者。他似乎确实回答了作为问题发布的问题......如果它们是相关的。

jSerialComm中没有异常句柄？

1 个答案: