4 ms·

I don't know how this is better. Just looking at the signature I don't believe this is more powerful or elegant than the same equivalent in Java: - what exactly

by mtrovo 6y ago

I don't know how this is better. Just looking at the signature I don't believe this is more powerful or elegant than the same equivalent in Java: - what exactly the object is doing with your error, I assume this is an IO monad so no changes are applied on the right side after an error but to be sure I would have to look at the library doc and rely on it rather than having this behavior enforced as part of the language design. - it doesn't require you to handle the exception or be clear that you handled it, for me this is a big problem of using Either, it treats error as one alternative of the code rather than something unusual that needs to be handled ASAP. If the compiler doesn't enforce it 99% of the cases nobody care to treat it at the right application layer which makes it very difficult to debug. - not strictly about your example but in Scala there's no standard way to handle exceptions, so if you're required to integrate this code with a library outside ZIO that uses a different pattern (java exceptions, Either, value classes, etc) it would start to feel you're writing a lot of glue code that should be part of the language design itself. I still feel Java is the baseline on how to bring exceptions to the language design and I believe part of the success of Java as a stable and predictable language is because of it. I feel a lot of the times new programming languages try to avoid java exception handling system because it's too verbose or brittle just to arrive in some solution that trade out the verbose checked code but doesn't deliver any feature on the same level.

esarbe 6y ago
IO is a monad, so you get pretty nifty composition out-of-the-box already with Scala. Since it's ZIO, you get even nicer error handling that you would with, say, cats' IO, where you i.e. have to deal with nested Monads and need to use Monad transformers, but that's another story. > or me this is a big problem of using Either, it treats error as one alternative of the code rather than something unusual that needs to be handled ASAP. But that depends on the use-case. There are several 'kinds' of errors and some of them have to be treated - as you put it - "one alternative of the code". If it's a communication error, you might want to retry instead of fail immediately, for example. If you are validating user input, retrying doesn't make sense, so there you want to fail fast. > If the compiler doesn't enforce it 99% of the cases nobody care to treat it at the right application layer which makes it very difficult to debug. Not quite sure what you mean by that. Care to rephrase? > in Scala there's no standard way to handle exceptions, But of course. It's `try (f()) catch { case e: .... }`. That's one and only way to handle exceptions in Scala. After an exception has been caught, you of course can lift the errors into any data structure you want (Try, Either, IO, ZIO,...).
- mtrovo 6y ago
  > Not quite sure what you mean by that. Care to rephrase? It should be hard or impossible to produce code that doesn't catch an exception or ignore it and just bubble the exception up on the call stack. The consequence of it is that sometimes it's easy to have a low level exception arriving on your presentation layer, which totally breaks encapsulation. > But of course. It's `try (f()) catch { case e: .... }`. That's one and only way to handle exceptions in Scala. After an exception has been caught, you of course can lift the errors into any data structure you want (Try, Either, IO, ZIO,...). That may be true for Java Exceptions but not 100% true for the generic concept of errors. You have try-catch which was inherited from JVM but most of my experience working in Scala people would call it a bad pattern and prefer using Either monads. The problem then being that Either try to solve something on the user code space that is already solved on the JVM level. And in a very poor way, think how in Java you can do a try-catch with type unions on the catch clause, or how you can catch and easily transform an exception into a totally different one and declare your signature on the most restrictive exception type. And the list of awkwardness goes on, see if you would use the same strategy to handle exceptions on the following examples: - code dealing with Java libraries - code dealing with Futures - code dealing with Either or other monads with left/error side - code that have to interact with different helper libraries (like cats or shapeless) - Either.map over a value that could produce a RuntimeException (e.g atoi)

by mtrovo 6y ago

esarbe 6y ago

IO is a monad, so you get pretty nifty composition out-of-the-box already with Scala. Since it's ZIO, you get even nicer error handling that you would with, say, cats' IO, where you i.e. have to deal with nested Monads and need to use Monad transformers, but that's another story. > or me this is a big problem of using Either, it treats error as one alternative of the code rather than something unusual that needs to be handled ASAP. But that depends on the use-case. There are several 'kinds' of errors and some of them have to be treated - as you put it - "one alternative of the code". If it's a communication error, you might want to retry instead of fail immediately, for example. If you are validating user input, retrying doesn't make sense, so there you want to fail fast. > If the compiler doesn't enforce it 99% of the cases nobody care to treat it at the right application layer which makes it very difficult to debug. Not quite sure what you mean by that. Care to rephrase? > in Scala there's no standard way to handle exceptions, But of course. It's `try (f()) catch { case e: .... }`. That's one and only way to handle exceptions in Scala. After an exception has been caught, you of course can lift the errors into any data structure you want (Try, Either, IO, ZIO,...).

mtrovo 6y ago
> Not quite sure what you mean by that. Care to rephrase? It should be hard or impossible to produce code that doesn't catch an exception or ignore it and just bubble the exception up on the call stack. The consequence of it is that sometimes it's easy to have a low level exception arriving on your presentation layer, which totally breaks encapsulation. > But of course. It's `try (f()) catch { case e: .... }`. That's one and only way to handle exceptions in Scala. After an exception has been caught, you of course can lift the errors into any data structure you want (Try, Either, IO, ZIO,...). That may be true for Java Exceptions but not 100% true for the generic concept of errors. You have try-catch which was inherited from JVM but most of my experience working in Scala people would call it a bad pattern and prefer using Either monads. The problem then being that Either try to solve something on the user code space that is already solved on the JVM level. And in a very poor way, think how in Java you can do a try-catch with type unions on the catch clause, or how you can catch and easily transform an exception into a totally different one and declare your signature on the most restrictive exception type. And the list of awkwardness goes on, see if you would use the same strategy to handle exceptions on the following examples: - code dealing with Java libraries - code dealing with Futures - code dealing with Either or other monads with left/error side - code that have to interact with different helper libraries (like cats or shapeless) - Either.map over a value that could produce a RuntimeException (e.g atoi)