> 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

> 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)