Skip to content

Conversation

@iRevive
Copy link

@iRevive iRevive commented Oct 24, 2025

https://typelevel.org/blog/2025/09/02/custom-error-types.html

Since we catch this error at the boundary, this whole process is entirely invisible to you unless you write something like handleErrorWith and catch all Throwable-typed errors within the scope, in which case you might see something of type Submarine. The correct thing to do with this error type, should you see it, depends considerably on exactly why you’re writing handleErrorWith, and as it turns out this is exactly the whole point!

It's relatively easy to run into problems when you call standard error-handling on an expression that requires Raise.
The new rule forbids using error-handling options. For example:

def raiseError: Raise[IO, String] ?=> IO[Unit] = r =>
  r.raise("boom")

def standardError: IO[Unit] =
  IO.raiseError(new RuntimeException("boom"))

Handle.allow[String] {
  for {
    _ <- raiseError.onError(e => IO.println("Error: " + e)) // forbidden
    _ <- standardError.onError(e => IO.println("Error: " + e)) // allowed
  } yield 
}

@iRevive iRevive force-pushed the topic/mtl-submarine-rule branch from b707f50 to 285de63 Compare October 24, 2025 14:09
@iRevive iRevive force-pushed the topic/mtl-submarine-rule branch from 285de63 to 3979797 Compare October 24, 2025 14:15
@iRevive iRevive changed the title Add a TypelevelMTLSubmarine rule Add a TypelevelMTLSubmarine rule Oct 25, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant