The plan is good as long as there is an 'error id'-like thing at the beginning of the error message string... Nothing is so frustrating than having to test against the full string... Good practice for that is always to add an id followed by a delimiter followed by the text... last but not least for simple, clear communication (and translation, if so needed). Since it is (unfortunately) just defined as error, there is not much to root for the id to have prefix, such as, for example, E for error... If it is though possible to make the information more purposeful - such as a status info - then such messages could look like:
I34 Info message text
W03 Warning message text
E20 Error message text
And even more smart, it would be a return status object... If that is too much a challenge because it comes from the low level (assembler) guts, (all or just) the message could be an object in JSON: 'E20 {type:"e", msg:"error message text"}'... With memory in demand though, 20 (number, any sort of integer) or '20' (or 'E20') is good enough (because 0 or '0' work well in the JS testing if (err) or if (err == 0) (...of course, not everyone likes or is a friend of the conversion ambiguity...)
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
The plan is good as long as there is an 'error id'-like thing at the beginning of the error message string... Nothing is so frustrating than having to test against the full string... Good practice for that is always to add an id followed by a delimiter followed by the text... last but not least for simple, clear communication (and translation, if so needed). Since it is (unfortunately) just defined as error, there is not much to root for the id to have prefix, such as, for example, E for error... If it is though possible to make the information more purposeful - such as a status info - then such messages could look like:
And even more smart, it would be a return status object... If that is too much a challenge because it comes from the low level (assembler) guts, (all or just) the message could be an object in JSON: 'E20 {type:"e", msg:"error message text"}'... With memory in demand though, 20 (number, any sort of integer) or '20' (or 'E20') is good enough (because 0 or '0' work well in the JS testing
if (err)
orif (err == 0)
(...of course, not everyone likes or is a friend of the conversion ambiguity...)