5 ms·

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

by jayd16 1y ago

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 1y ago
> Why not just Exit if that's the proper thing to do? Because you won't get a stack trace.
vips7L 1y ago
Checked exceptions could still work across lambdas. Scala is doing research there: https://docs.scala-lang.org/scala3/reference/experimental/canthrow.html https://docs.scala-lang.org/scala3/reference/experimental/ca...
- int_19h 1y ago
  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 1y ago
    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 1y ago
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-avoid-exceptions.html 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 1y ago
  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.

by jayd16 1y ago

breadwinner 1y ago

> Why not just Exit if that's the proper thing to do? Because you won't get a stack trace.

vips7L 1y ago

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

int_19h 1y ago
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 1y ago
  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 1y ago

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-avoid-exceptions.html 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 1y ago
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.