From 4c7fc9a2b918942c434c552ca101d64769b1a699 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ivan=20=E2=80=9CCLOVIS=E2=80=9D=20Canet?= Date: Wed, 18 Oct 2023 16:12:04 +0200 Subject: [PATCH] Mention Raise.traced in the Typed Errors page (#247) > Issue: #245 I believe `traced` is sufficiently well explained in the API docs that it's not worth adding an entire paragraph to the main documentation, and a simple mention is enough (for discoverability / for users who know it exists but do not know where to find it). Therefore, this PR adds a short information note to the "Running and inspecting results" mentioning the feature. --- .../docs/learn/typed-errors/working-with-typed-errors.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/content/docs/learn/typed-errors/working-with-typed-errors.md b/content/docs/learn/typed-errors/working-with-typed-errors.md index 020e940a..05e778fa 100644 --- a/content/docs/learn/typed-errors/working-with-typed-errors.md +++ b/content/docs/learn/typed-errors/working-with-typed-errors.md @@ -426,6 +426,12 @@ fun problematic(n: Int): Either = ::: +::: info Tracing the origin of a raise + +As projects grow in size, raised errors propagate through the call stack. To make debugging easier, Arrow provides a way to trace calls to `raise` and `bind`: [see Raise.traced](https://apidocs.arrow-kt.io/arrow-core/arrow.core.raise/traced.html). + +::: + ## Recovering from typed errors We've already hinted this distinction above, but with working with type errors it's important to distinguish between two kinds of _problems_ that may arise: