Skip to content

Conversation

@MarcellPerger1
Copy link
Owner

@MarcellPerger1 MarcellPerger1 commented May 5, 2024

  • Result type (similar to Rust's)
  • (Maybe?) Rust Option type (could be useful)
  • Tests for Result/Option type

Decided not to:

  • Use new Result type everywhere in parser code
  • Update Parser tests to test for error handling

Fixes #3

Implements all methods present on Rust's `Result` type
that can actually be implemented in Java and in a more Java-esque style.
There were some methods that are impractical / impossible to implement in Java:
- `unchecked_*` for obvious reasons
- `unwrap_or_default`: no static polymorphism - more info in the big comment
- `into_ok`: No infallible/`!` type in Java, not enough stuff at compile time to work (see comment)
- The `impl`s on nested `Result` types, etc. as we can only have 1 class-wide constraint (see comment). Although we could make those `static` methods if we really need them.

Possibly, we could also make an `Option<T>` class for more convenience.
@MarcellPerger1

This comment was marked as resolved.

@MarcellPerger1
Copy link
Owner Author

Actually, I'm not sure using Result everywhere is a good idea - try/catch has more natural-looking code and can using Result.fromTry in special cases within functions

Checked exceptions are much more ergonomic has they have first-class language support and syntax, unlike my Result type.
@MarcellPerger1 MarcellPerger1 marked this pull request as ready for review May 27, 2024 19:44
@MarcellPerger1 MarcellPerger1 merged commit c655e84 into main May 27, 2024
@MarcellPerger1 MarcellPerger1 deleted the fix-error-handling branch May 27, 2024 20:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[parser] Figure out how to do the exception handling nicely and consistently

2 participants