Improve color parser error handling for clarity and robustness #27
Description
Background
This issue is dependent on the completion of #26 (RGB/HSL tuple disambiguation) and aims to further strengthen the error handling logic for the color parser.
Current Problem
While the parser is comprehensive, some error messages can be ambiguous or overly technical, and not all cases of validation failure produce actionable or clear feedback. It's important for maintainers and end-users that:
- Error messages are clear, concise, and in simple language
- All failure points (invalid input/type, range errors, unsupported formats, etc.) fail gracefully, raising ValueError with useful context
- Program logic should avoid uncaught exceptions or ambiguous error states
What to do
- Review every function in
color_parser.pywhere user input is parsed or validated - Ensure each invalid input path produces a clear, actionable error message (not just "ValueError" or a stacktrace)
- Avoid jargon or overly technical explanations in error strings
- Where possible, suggest correct formats or alternatives in the error
- Add tests that verify invalid/color edge cases fail with the right message (do not leak tracebacks)
- Ensure all exceptions fall back to python's ValueError or TypeError, not unhandled
Example improvements:
- "RGB component out of range: {c}" → "Each RGB color should be between 0 and 255. Got: {c}"
- "Unrecognized color string format" → "Color not recognized. Please use a standard CSS color name, hex, rgb(), or hsl() format."
- All code paths should be robust to informally formatted or totally invalid input
Goal:
Make the parser's error-handling UX world-class! Failures must be clear, constructive, and non-alarming for all typical and edge-case invalid input values.
Dependencies:
This issue is blocked by #26 and should be started only after it is merged.