Report serial port and verification failures - #38
Conversation
Commands that open a serial port report a recognized port failure as a message and exit 1, instead of an unhandled exception. Reporting is attached to the port option, so the message names the option it belongs to, and port options share a base class so --clock-port can adopt it. Verifying a port that does not exist fails immediately rather than retrying for ten seconds, and a verification run reporting a failed or errored check exits 1 while skipped checks still exit 0. Unrecognized exceptions are left to the default handler unchanged.
The exit code is now documented as 1 when any check failed or ended in error and 0 otherwise. Skipped checks do not affect it, and a run that cannot start also exits 1. The results paragraph names all four outcomes rather than three, and no longer says a device that stops answering fails the check waiting on it, since an unanswered read ends that check in error. Version replaces revision throughout, except where the text at a specification commit is meant, and three clauses ending on a stranded verb are rewritten.
banchan86
left a comment
banchan86
left a comment
There was a problem hiding this comment.
Tested several different configurations and mostly looks good to me so far!
The checks will report a port closed exception if the system recognizes that the device properly disconnected and the COM port is closed, but one thing I did run into is that if i just unplug the device, the checks can report a TimeoutException but the checks don't actually wait for the timeout and just speeds through the checks. Reproduced twice on both Behavior board and Timestamp Gen.
report-v1-disconnect-timeoutexception.html
timestamp-generator-report-v2-disconnect-timeoutexception.html
Beyond correcting the error message so that it reports the right thing, I guess I was also wondering what the default behavior is if it does encounter a single timeout on a single check. Like is it supposed to error out for the rest of the report, or does it give the next check the proper timeout. I am not sure how to make a single register timeout though haha.
2 participants
Commands that open a serial port now report a recognized port failure as a message and exit 1, instead of ending in an unhandled exception and a stack trace. The reporting is attached to the port option itself, so the message names the option that supplied the port name, and an unrecognized exception is never caught, leaving the default
System.CommandLinehandler to report genuinely unexpected errors.verifynow exits 1 when any check failed or ended in error, and 0 otherwise, so a script can act on the result. Skipped checks do not affect it.Two smaller changes come with it. Port options share a base class, so
--portand--clock-portare both port options and the reporting applies to either, with--clock-portmoving out of an inline declaration into a class of its own like every other option in the toolkit. And verifying a port that does not exist fails immediately rather than consuming the full ten seconds of the open retry budget, since a missing port failure is permanent.Documentation
The verify article now states the exit code, names all four check outcomes rather than three, and no longer says a device that stops answering fails the check waiting on it, since an unanswered read ends that check in error. Version replaces revision throughout, except where the text at a specification commit is meant.
Verified on hardware
Measured against a Behavior device running firmware 3.2 with harp core 1.13, which declares no protocol version.
verify --port COM3verify --port COM3 --prereleaseBoth reproduce the outcome counts recorded before this change, so wrapping the command in the port error reporting altered no check result. The port failures were measured separately, covering a port that does not exist, a name that is not a serial port, and a missing firmware file, the last of which still prints its full exception rather than being misreported as a port error.