Sollten immer alle Fallen definiert sein?

Ich habe jetzt zwei Fälle mit dsPIC 30F4013 gesehen, in denen der Controller aufgrund einer undefinierten Falle zurückgesetzt wurde. Warum diese Fallen überhaupt aufgetaucht sind, ist immer noch ein Rätsel, aber das ist nicht meine unmittelbare Frage. Ich fange an zu denken, dass es eine gute Programmierpraxis wäre, immer alle Traps zu definieren, auch wenn Traps niemals auftreten sollten, sodass ich zumindest eine eindeutige Fehlermeldung anstelle eines zufälligen Zurücksetzens erhalte. Ist dies eine Standardpraxis, die ich nicht kenne? Gibt es Nachteile bei dieser Vorgehensweise, die ich berücksichtigen sollte?

Meine informelle Regel lautet:

1. Wenn ein Interrupt aktiviert ist, sollten Sie über Code verfügen, der ihn verarbeitet.
2. Wenn Sie keinen Code für einen Interrupt schreiben, deaktivieren Sie ihn.
3. Wenn Sie es nicht deaktivieren können, schreiben Sie Code dafür.

Auch ohne diese Regel beantwortet das Datenblatt Ihre Frage explizit:

Wenn der Benutzer im Falle eines Trap-Fehlerzustands keine Korrekturmaßnahmen ergreifen möchte, müssen diese Vektoren mit der Adresse eines Standard-Handlers geladen werden, der lediglich den RESET-Befehl enthält. Wenn andererseits einer der Vektoren, die eine ungültige Adresse enthalten, aufgerufen wird, wird eine Adressfehlerfalle erzeugt.

( Quelle , Abschnitt 8.3, erste Anmerkung)

Da Sie keine Fallen maskieren können, müssen Sie mit ihnen umgehen. Wenn Sie die Falle nicht auf bestimmte Weise behandeln möchten, müssen Sie eine RESETAnweisung ausführen .

Ja, es ist eine gute Idee - der einzige Nachteil ist die zusätzliche Codegröße, und Sie müssen entscheiden, was mit der Falle geschehen soll (eine Meldung über die serielle Schnittstelle ausgeben? Eine "FAILED" - Anzeige einschalten? Stiller Neustart usw.) )