Description

So far, the library currently provides a Result type (with Ok and Err), but it does not include a Try monad. In many Java functional-style APIs, Try serves as a convenient abstraction for wrapping computations that may throw exceptions, especially when dealing with:

• Exception-throwing operations that cannot be easily expressed as pure functions
• Interop with legacy Java APIs
• Converting imperative exception flows into composable monadic pipelines
• Safely sequencing potentially failing operations without cluttering code with try/catch

A typical Try monad also enables operations such as:

• Try.of(...)
• map, flatMap, recover, recoverWith
• Converting to/from Result
• Collecting or sequencing multiple computations

Why is this useful?

Adding a Try type would provide:

• A unified and predictable model for exception-handling in functional style
• Better ergonomics when composing effectful computations
• Parity with other well-known functional libraries (Vavr, Arrow, Scala standard library)
• A consistent monadic family (Option, Result, Try, etc.)

Proposed direction

I'd like to request adding a Try type with semantics similar to the common functional pattern:

Try<Integer> t = Try.of(() -> riskyOperation())
    .map(x -> x * 2)
    .recover(e -> 0);