What am I doing wrong with `Raise<R>` , how ...

# arrow

[Norbi]

What am I doing wrong with Raise<R> , how should I use it in "real" code?
My problem is:
1. I've found that very often I want to know the root cause of an error - so I've reinvented the cause mechanism of exceptions 😐
2. I've found that by handling raise() -d errors, the contextual information is lost at the top level, where I maybe want to log a stack trace for easier investigation of the problem.
Do you have some practical advice for using it?
Maybe my head has just "stuck" thinking only by exceptions 🙂
Thanks.

[Sam]

If it’s an error where you want to log a stack trace, maybe you should just use an exception

[simon.vergauwen]

For 1, this might be due to the fact you're also capturing truly exceptionally things. Often you don't want to capture all exceptions when for example wrapping PSQLException, but only reify UNIQUE_VIOLATION to UserAlreadyExists. Keeping the cause around is definitely advised if you want to capture truly exceptionally things, which is often done in something like UnkownError.

For 2, I have this PR open. Tracing POC and I am eagerly looking for feedback. This allows you to get stack traces for Raise<E>.

[CLOVIS]

What I did, and now recognize to be a mistake, is that I wrote the entire program with what was essentially Raise<String>. If you do this, you do indeed lose all context.

However, if you create a proper failure type for your various endpoints, any value gives you the entire context, and you can easily insert logging/breakpoints to find out what the result of any function is. It also makes I18n for errors trivial 🙂

[Norbi]

often done in something like UnkownError

Yes, I use it regularly like:

sealed interface SomeFunctionError {

   data class CalculationError(...): SomeFunctionError

   ...

   data class UnknownError(val someContextAboutTheException: Any, ..., val cause: Exception): SomeFunctionError
}

So probably I should simply remove the SomeFunctionError sub-type wrapping the exception, and create a specific RuntimeException subclass instead?

Hmmm, it is not easy to structure the code with "two levels" of error handling.

Thanks for the advice for everyone!

[simon.vergauwen]

So probably I should simply remove the SomeFunctionError sub-type wrapping the exception, and create a specific RuntimeException subclass instead?

Uhm, don't think that is what I meant 😅 What are you currently using UnkownError for?

@CLOVIS you seemed a bit surprised by my comment.

[CLOVIS]

Sorry, I'm just very interested by the tracing feature. IMO it's the biggest drawback to Arrow's error handling, you can't stracktrace-debug stuff.

[simon.vergauwen]

Oh, that's great to hear. It's indeed a feature typically lacking of functional error systems, and there is all kinds of design for it. I am currently contemplating adding @ExperimentalTracing 🙈 on it and merging it 😁

@Norbi here you can see the difference in practice.

Ktor Arrow Example wraps exceptional things in Unexpected with a description and carrying the cause: Throwable. At the edge these are logged and turned into 500.

Gh Alerts Subscription Service allows exceptional things to remain as Throwable and only turns expected domain exceptions into UserNotFound in the linked case. Any uncaught exceptions are resolved by Ktor into 500.

It depends a bit on use-case to use-case, but the second approach is I think more often used. You can gradually add more typed errors for only cases you care to track in the type system. If my application cares about "Database timeout", or "Table Deadlock", etc then I can lift it into Raise<E> but most applications don't care about that.

[Norbi]

What are you currently using UnkownError for?

Mainly for wrapping (general) exceptions thrown by external functions when I invoke them. What I find difficult is to bridge the exception-only external world with my raise()-abundant own code...

[simon.vergauwen]

I think the second link I shared might give you better insights on how to do that, but please feel free to ask more questions ☺️ This reminds me that I probably need to write a section for the new website on this. (Which will probably be released in preview this month with 1.2.0-RC)