[jayd16]

Java streams and a lot of other APIs are extremely ugly because of checked exceptions. Conversely, LINQ and delegates and a lot of other syntax is far cleaner in C#.

Your linked blog is pretty wild. Only throw RuntimeExceptions to crash? Why not just Exit if that's the proper thing to do?

If you treat all C# exceptions as RuntimeExceptions, then it satisfies the blog anyhow.

[breadwinner]

Side effects are not allowed in functional style programming. Exceptions are side effects, it doesn't matter whether they are checked or unchecked exceptions.

https://jessewarden.com/2021/07/why-functional-programmers-a...

While composing methods in stream style is convenient, methods that can throw exceptions warrant more careful coding, so convenience should not always be the priority.

[int_19h]

Exceptions are not side effects since no state mutation occurs.

If you really want to see everything through the FP lens, exceptions are exactly like Result<T, E> with implicit do-notation.

[vips7L]

Checked exceptions could still work across lambdas. Scala is doing research there: https://docs.scala-lang.org/scala3/reference/experimental/ca...

[int_19h]

One of the original lambda proposals for Java - the one from Neal Gafter - also had checked exceptions.

The problem is that you then need a way to capture exception specifications as generic type parameters to properly propagate contracts, which complicates the type system quite a bit. Which is why Java ultimately went with the much simpler proposal that didn't even try to tackle this.

[vips7L]

Yes I'm well aware, but that is uniquely a Java problem. With a sufficiently strong type system, like the one in Scala, you can easily make checked exceptions work across higher order functions.

[breadwinner]

> Why not just Exit if that's the proper thing to do?

Because you won't get a stack trace.