You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
_writeBytes just returns true/false on success/failure without any further details. But write() would provide (potentially useful) error details (For example see a list at its man page).
Further, SerialPort.writeBytes just communicates errors by returning false. This has potential to fool java developers. As they're used to get exceptions thrown if someting is wrong. Java code, checking for returned success/failure codes is something I see seldom. I even found exactly this mistake in our projects codebase which is using jssc. This is not meant to blame java devs. It's just when writing java, one easily overlooks this as one is used to exceptions and does not expect a method where the return value suddenly should be checked (in contrast of all other methods around id).
Expected Behavior
IMHO we should provide more error details to our caller. I see multiple ways to do so. Eg we could throw java exceptions (for example from SerialPort class but also from native code would be possible). Or returning numerical codes, Or providing some kind of getError() method (not very nice, but better than nothing) alongside with the returned boolean where caller can retrieve an error message. Or ... whatever.
The text was updated successfully, but these errors were encountered:
Some thoughts about
java-native#129
and
java-native#96
What this commit does:
- Make native impls return numberOfBytesWritten.
- Throw SerialPortException in case write fails in some way.
- Expose new 'write()' method to java which returns
numberOfBytesWritten and uses exceptions for error handling.
- Keep old 'writeBytes()' method and translate to the old behavior.
What this commit does NOT:
THIS CODE IS NOT TESTED! It even was not launched at all. Nevertheless
it did compile fine for x86_64-linux-gnu (debian) and mingw
(cross-compile). So we need to do:
- Testing!
- Review if the change in the API (adding a 'write()' method) is the
thing we should do or if we should do it differently somehow.
(wip @ 36ee5d8)
Actual Behavior
Method
Conceals error details.
_writeBytes just returns true/false on success/failure without any further details. But write() would provide (potentially useful) error details (For example see a list at its man page).
Further, SerialPort.writeBytes just communicates errors by returning false. This has potential to fool java developers. As they're used to get exceptions thrown if someting is wrong. Java code, checking for returned success/failure codes is something I see seldom. I even found exactly this mistake in our projects codebase which is using jssc. This is not meant to blame java devs. It's just when writing java, one easily overlooks this as one is used to exceptions and does not expect a method where the return value suddenly should be checked (in contrast of all other methods around id).
Expected Behavior
IMHO we should provide more error details to our caller. I see multiple ways to do so. Eg we could throw java exceptions (for example from SerialPort class but also from native code would be possible). Or returning numerical codes, Or providing some kind of getError() method (not very nice, but better than nothing) alongside with the returned boolean where caller can retrieve an error message. Or ... whatever.
The text was updated successfully, but these errors were encountered: