[happytoexplain]

>if you are throwing an error in most of the languages your caller function will not get an idea that this function can throw an error

Is this true any more? I feel like most languages, relative to popularity, have compiler-enforced thrown error handling.

[gdprrrr]

C# is one of the offenders. And while Java has checked exceptions, many considered Thema an annoyance and wrap everything in RuntimeException.

[flakes]

Very true. Checked exceptions in Java are a form of function coloring problem for modern libraries.

Especially painful when using any of the functional style stream operations, like `map`, `filter`, etc, or any other higher order function library. Most take in the standard `Function` or `BiFunction` interface arguments, which will not support method referencing for anything which includes a checked exception as part of its signature.

[gpderetta]

But a better language would allow generalizing over exceptions. In pseudo C++:

  auto map(collection<T> C collection, function<T> F f) -> invoke_result<F, T> throws(invoke_exception<F, T>);

[TeMPOraL]

> Checked exceptions in Java are a form of function coloring problem for modern libraries.

So is returning result or error via Either/Expect/Result sum types. Exceptions or Expected, code gets messed up either way.

[flakes]

Not quite of the same caliber. A checked exception has the form `R func(T t) throws Err`. A concrete result type (like Rust has) would look like `Result<R, Err> func(T t)`.

The later fits nicely into the `Function<,>` interface, `Function<T, Result<R, Err>>` vs the former requires a different interface entirely, something like `FuncE<T, R, Err>` where `Err` breaks out into an argument for the throws value of the signature.

Because most of the functional libraries in Java work with Function, BiFunction, etc, we end up with incompatible arguments for common patterns such as `map`, `filter`, etc.

[aiunboxed]

Typescript, Python all are exception