¿Cómo se usa el manejo de excepciones en el software incorporado?

Mi experiencia es que se evita. Si bien no existe una razón intrínseca por la que no se deba utilizar, el hábito de transmitir el problema a otra persona es malo para los diseñadores integrados. Tienden a (a) querer entender y explicar cualquier problema en el momento del diseño y (b) manejar los problemas lo más cerca posible de la fuente.

Un patrón es hacer verificaciones por adelantado para que no se produzca ningún error, en lugar de verificar sobre la marcha y lanzar una excepción cuando se produce una. Otro es proporcionar almacenamiento explícito para los datos de error que pueden inspeccionarse cuando se devuelve un error.

La política de manejo de excepciones es algo que debe establecerse muy temprano en el diseño de un sistema embebido y debe cumplirse rigurosamente. Mi experiencia es que las excepciones se consideran más problemas y más riesgos de lo que valen. No pases tus problemas a otra persona, arréglalos.

Si un programa incrustado se escribe correctamente, las excepciones como dividir por cero deberían ser imposibles, ya que, por definición, un sistema incrustado ejecuta un solo programa para siempre y todos los estados posibles se pueden resolver por adelantado. Sin embargo, un diseñador prudente siempre pone una trampa de error crítico y una rutina de recuperación, y / o un temporizador de vigilancia. De esa forma, evitan problemas como los que tengo con mi nueva máquina de café, que ocasionalmente se bloquea y debe desconectarse para restablecerla.