Enhancement: Runtime Error Detect and Alert

[mikaelpatel]

Some of the types of programming errors that newcomers do could be captured (i.e. detected and displayed).

Several of the core functions and classes use the heap (i.e. function malloc/free) with limited detection of when the heap is exhausted. Often the error is simply passed to the sketch without notice. A good example is String which generates very many questions on the forum. Also the implementation of new and delete do much the same; pass the error situation to the sketch.

Another area of concern is program lockups, i.e. sketch functions that do not return due to poor designed algorithms or hardware/wiring errors. In these cases a simple watchdog could be used to capture and signal the error state. Please see #5673.

A possible method of signaling the error situation is to use the board LED (with a rapid blink with/without pause) alternatively print to Serial (if available).

The proposal is 1) detect heap allocation failure (in core functions) and program lockup, 2) alert using LED and/or Serial.

[per1234]

use the board LED (with a rapid blink with/without pause)

What if I have something connected to that pin that I don't want toggled on and off when there is an error?

alternatively print to Serial (if available).

Won't that incur significant overhead?

I think passing errors to the sketch and documenting that behavior is very important but the decision of what to do about the error should be left to the user.

Maybe these ideas(along with your "watchdog" system) could be implemented in a 3rd party "training wheels" core instead?

[mikaelpatel]

I fully agree that there are many questions to be asked, and design to be discussed but I believe that newcomers to Arduino programming need better support in at least these areas.

After a few years of reading and answering (at least a few) issues on Stackexchange and the Arduino forum I have come to the conclusion that we actually could do a better job at supporting run-time error detection and reporting from the core functions (and classes). I think "training wheels" is a very good way at looking at this.

From the core function point of view there is actually only one method of reporting (alert); blinking the on-board LED. Printing an error message to Serial requires a lot more.

After detecting memory error or program lock-up there is not very much to do more than "blink". Even restart (true watchdog) is too advanced.

Last, I do not see the need to create a 3rd part core for this. Instead a few hooks (for main, millis timer isr and malloc) together with a wrapper (for malloc) would be sufficient without any major performance loss. But this is getting into design and implementation sketching before doing the requirements job.

[matthijskooijman]

I suppose some kind of error reporting / logging framework could make sense, I've missed this when writing libraries as well. I would think it needs to be opt-in for the sketch (e.g. say Errors.reportTo(Serial);, or Errors.reportToLed(13);) to make sure things actually get reported to a sensible place. If not enabled, the error reporting is just a no-op.

I also think the error reporting should be available to libraries as well, e.g. they should be able to call Errors.report(Errors::WARNING, F("Sensor not connected")) (e.g. with an error code and message). The error codes might be more specific, things like "out of memory" might need their own error code (and blink pattern).

Finally, this is something that must be in the core (as opposed to in a library), since otherwise the core itself cannot use it.