Just a quick check-in to see how other people are handling errors in their firmware. Software errors specific to user code type things. I am working on a fairly involved firmware and am trying to decide the best way to “trap” errors for publish when in normal mode plus a verbose mode that will throw data via Serial and Publish.
If I have the device close I most of the time use Serial and some colours on the LED 
Yeah thats my “local testing” method too but I have devices that will be outside and hopefully eventually in the field owned by customers. Looking for suggestions on how to structure error handling and the like for a device I can’t physically plug into/see.
Well, publish could do but you have limitations as publish rate and the device losing network connection.
Best way to update the devices of customers is to test it first locally on your own particle and after it works you push it to the customers. That depends on your application though.
@LukeUSMC, I have a similar situation with my code. Some errors like no WiFi can’t rely on publish. Others may be device specific like a failed SD for example. In my case, it comes down to the system “state”. If the unit is cloud connected, I publish. If it is wifi connected, I POST a message to a server. If wifi is not connected, I log the error in eeprom, understanding that this data may be used post-mortem after the unit is sent back or I can get to it.
For some errors, the unit is no longer considered usable (unless serviced) so I follow the logic above and put the system in non-timed deep sleep since it is battery operated. Clearly understanding and planning for all predictable failure modes is always fun 