Problem
Currently, several functions (notably in markdown.c and math.c) silently fail or degrade on parsing errors, malformed input, or buffer overflows – often just returning early without warning or feedback (see comments marked 'fail silent' and 'return'). This approach makes debugging harder, conceals bugs, and prevents both users and developers from knowing when or why content rendering failed.
Proposed Solution
- Introduce error return codes and/or status objects for parser entry points
- Add logging (to console, or dev-only output buffer) when parsing fails, or a buffer overflow is detected
- Optionally display an in-app or console warning if fatal rendering issues occur
- Add test cases for both user-facing and dev-facing error reporting
- Document error propagation and handling conventions
Acceptance Criteria
- All parsing errors and buffer overflows are detected and logged during development
- Runtime never fails silently; in production, error state is at minimum measurable/observable
- Documented API/code conventions for error handling
References
Problem
Currently, several functions (notably in markdown.c and math.c) silently fail or degrade on parsing errors, malformed input, or buffer overflows – often just returning early without warning or feedback (see comments marked 'fail silent' and 'return'). This approach makes debugging harder, conceals bugs, and prevents both users and developers from knowing when or why content rendering failed.
Proposed Solution
Acceptance Criteria
References