On Mon, 2 Mar 2026 16:04:12 GMT, Michael Strauß <[email protected]> wrote:
> `CssParser.colorValueOfString()` parses a string into a `Color`. If this > fails by throwing an exception, `null` is returned from > `colorValueOfString()`, signalling to the caller that the color string might > be a lookup instead. > > Since color lookups can appear in many places in a CSS file, it is preferable > to use return values for flow control instead of exceptions. For this > purpose, we need non-throwing versions of methods that parse numbers and > colors. > > These are the changes in this PR: > 1. Move color parsing from the `Color` class to `CssColorParser`. This is > done so that we can access the new `tryParseColor(String)` method from > `CssParser`, and also to separate concerns between color representation and > parsing. > 2. Add a non-throwing `CssNumberParser.tryParseDouble()`, which returns `NaN` > to indicate a parsing failure. We can use `NaN` because it is not a valid > return value of the parser. > 3. Since color parsing also uses `Integer.parseInt()`, we need a non-throwing > version of this method: `CssNumberParser.tryParseInt()`. Since we can't use > any particular `int` as a return value that indicates failure, I've decided > to return a `long` value instead, where a value less than `Integer.MIN_VALUE` > indicates a parsing failure. If it helps, an exception for flow control can be made a lot lighter by re-using a static exception, with its stack trace disabled. Make it checked as well to ensure it never escapes the parsing logic where the user might see an exception without a stack trace. I'm not really in favor of using `long` to signal problems with an `int`; I'd use either `Integer` or `OptionalInt`. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2093#issuecomment-3990255108
