Currently there are a small handful of scenarios where ansi_to_html::convert() can return an error. Specifically it's
Error::ParseInt(std::num::ParseIntError) gets returned if there's a number in an ansi code that's outside the 8-bit range e.g. \e[256m
Error::Invalid { msg: String } which can be returned when
- A couple of (i think unreachable based on all the call-sites) 4-bit color parsing
|
return Err(Error::InvalidAnsi { |
|
msg: format!("unexpected integer {} parsing 4-bit color", code), |
|
}) |
|
return Err(Error::InvalidAnsi { |
|
msg: format!("unexpected integer {} parsing bright 4-bit color", code), |
|
}) |
- Or an incorrectly structured 8-bit or RGB ansi sequence
|
.ok_or_else(Error::invalid_ansi("Missing 8-bit color"))?; |
|
let r = r.ok_or_else(Error::invalid_ansi("Missing ANSI red"))?; |
|
let g = g.ok_or_else(Error::invalid_ansi("Missing ANSI green"))?; |
|
let b = b.ok_or_else(Error::invalid_ansi("Missing ANSI blue"))?; |
|
return Err(Error::InvalidAnsi { |
|
msg: format!("Expected 2 or 5, got {}", code), |
|
}) |
I think it would be reasonable to instead ignore all of the current errors as invalid ansi codes instead of bailing out with an error. We could take an (optional?) dependency on some logging library and log some warning instead, or we could have an API that allows for returning the converted texts along with errors (and if so I would recommend returning a span indicating where the problematic text is and a more well typed error than a message String)
Currently there are a small handful of scenarios where
ansi_to_html::convert()can return an error. Specifically it'sError::ParseInt(std::num::ParseIntError)gets returned if there's a number in an ansi code that's outside the 8-bit range e.g.\e[256mError::Invalid { msg: String }which can be returned whento-html/crates/ansi-to-html/src/color.rs
Lines 25 to 27 in f95215d
to-html/crates/ansi-to-html/src/color.rs
Lines 43 to 45 in f95215d
to-html/crates/ansi-to-html/src/color.rs
Line 63 in f95215d
to-html/crates/ansi-to-html/src/color.rs
Lines 71 to 73 in f95215d
to-html/crates/ansi-to-html/src/color.rs
Lines 78 to 80 in f95215d
I think it would be reasonable to instead ignore all of the current errors as invalid ansi codes instead of bailing out with an error. We could take an (optional?) dependency on some logging library and log some warning instead, or we could have an API that allows for returning the converted texts along with errors (and if so I would recommend returning a span indicating where the problematic text is and a more well typed error than a message
String)