Closed nkrkv closed 5 years ago
I found some classes of errors. So here are error codes that I can propose to use (but not sure about numbers):
xod/gpio
)xod/i2c
)xod/i2c
, xod/uart
, xod/net
, xod-dev/esp*
, xod-dev/pn532-nfc
and etc)xod/net
, xod-dev/esp*
, xod-dev/w5500
).xod/net
, xod-dev/esp*
, xod-dev/w5500
)xod/common-hardware
, xod-dev/pn532-nfc
and etc). Probably, can be merged with the first one: "Invalid port"xod/i2c
)xod/i2c
)xod/i2c
)xod/i2c
)xod-dev/esp8266
, probably GPRS shield too etc)xod/common-hardware/hc-sr04-ultrasonic-time
).Probably we have to group it by classes (i2c, io, gpio, network, devices). And probably some hardware-specific errors should be at "user-land" space. For example, "No echo" error code of the ultrasonic range meter could have a number 101.
Moreover, "No echo" probably is not an error and should be left as an output pulse. The same thing with read-byte
. Should it raise an error if there are no available bytes to read, or just pulse to the output pulse "NA" (Not Available)?
Also, the whole error system reminds me of error codes from bash scripts. So, probably, all error codes should be node specific. analog-read
can't raise an error about internet connection like the any esp8266-mcu
can't raise "Invalid port" error.
@nkrkv @evgenykochetkov @knopki Please, tell me your thoughts about it.
First-class error support is coming to XOD. The standard library should use the new mechanism as it more flexible and because the standard library is an instance of how things should be done.
Currently, the following patches use ERR-pulses:
Let’s replace the ERR’s with error raising.
Acceptance criteria
104-button
)¹