Нет дескриптора исключения в jSerialComm?

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. проглотить исключение
3. какКак следствие 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; } }

Вот вопросы:

1. Почему исключение было проглочено, а прослушивание в библиотеке остановлено?Существуют ли какие-либо конструктивные причины?
2. Сам класс SerialPort равен final, и, следовательно, о написании моей собственной реализации класса для замены ласточки не может быть и речи.Как мне продолжить?Помимо этой проблемы, jSerialComm, по-видимому, удовлетворительно удовлетворяет большинству других вариантов использования, поэтому я не могу в скором времени перейти с него.
3. Один из способов - поймать его самостоятельно и выполнить обработку.Но я не хочу этого делать, если ответ на вопрос 1 не ясен.Я пытался исследовать, но не нашел никаких практических причин для отключения прослушивания и не объявлял об исключении.
4. Почему просто NPE, могут возникнуть и другие исключения.Так что, по крайней мере, мне придется самому обрабатывать исключения.Правильный ли тогда подход моих обработчиков?

TIA Rahul

Answer 1

1) Почему исключение было проглочено и прослушивание в библиотеке остановлено? Есть ли какие-то конструктивные причины?

Вам нужно будет спросить у автора кода.

Однако, это кажется преднамеренным, поскольку waitForSerialEvent объявлено как throws NullPointerException.

На вашем месте я бы глубже вникнул, куда бросают NPE и почему. Модифицируйте код, чтобы напечатать трассировку стека, а не просто полностью исключить исключение. Это может быть обходной путь или может быть законная причина для этого.

Если мы сделаем предположение, что код слушателя клиента может выдать NPE, то, на мой взгляд, ошибочно для потока событий предполагать, что все NPE могут быть раздавлены.

Но, глядя на код, я также могу видеть места, где NPE преднамеренно выбрасываются, чтобы (очевидно) сигнализировать об ошибке; например в методах read в SerialPortInputStream. Так что мне не ясно, что NPE должны быть раздавлены вообще.

2) Сам класс SerialPort является окончательным, и поэтому о моей собственной реализации класса для замены ласточки не может быть и речи. Как мне продолжить?

Код находится на GitHub, поэтому вы можете разветвить репозиторий, разработать патч и отправить запрос на извлечение.

4) Почему просто NPE, могут возникнуть и другие исключения. Так что, по крайней мере, мне придется самостоятельно обрабатывать исключения Правильный ли этот подход моих собственных обработчиков?

Хороший вопрос.

---

Но на самом деле все эти вопросы лучше адресовать автору кода. Кажется, он отвечает на вопросы, опубликованные как проблемы ... если они уместны.