[Proposal] Easily log an exception with a `crash_reason`

[Michael Bianco]

Hello!

I was working with the library Quantum. It allows you to run jobs/tasks on a cron-like schedule (very useful tool!). However, my jobs were failing and I wasn't being notified about the failure.

One of the reasons this was occurring is because Sentry (error tracking service) relies on the `crash_reason` metadata key to report exceptions. It turns out transforming `{kind, reason}` available in `catch` into the format required for `crash_reason` is not straightforward.

I was able to find a snippet of broadway code that accomplishes this:

https://github.com/dashbitco/broadway/blob/master/lib/broadway/topology/processor_stage.ex#L165-L179

Here's the patch I submitted to Quantum to perform similar logic:

https://github.com/quantum-elixir/quantum-core/pull/464/files

I think it would be very helpful to have a way to log exceptions that are caught in `catch`. Something like the `log_exception` function above, maybe built directly into the `Logger` module as a `exception` function? I don't have enough familiarity with the stdlib to have a good sense of where this function should go, but it feels important to have an easy way to log an exception in a way that will be picked up by logging backends watching for exceptions.

Curious what folks think!

Mike

[José Valim]

Hi Michael,

Thanks for the proposal and the PRs!

One of my concerns is that we are potentially promoting two "unhealthy" patterns:

1. rescuing exceptions - which is something you would do rarely and only when very justified. For example, Broadway does so to maintain the topology, since it is expensive to set up. Most other projects don't do this at all (Ecto, Phoenix, etc)

2. Having partial loggers. In my mind Sentry should log messages and there is even an option for doing so :)

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/c89c08e5-9879-414a-b668-0377fc2ab02an%40googlegroups.com.

[Jonatan Männchen]

Hi Josè,

I think that qunatum falls into pattern 1 here.

It would still be nice to have an official way to do it (where we encourage to use another option in the docs instead of that one) since that allows standardized error handling even with "special" projects.

Best,

Jony

[Michael Bianco]

Hey Jose,

Thanks for the thoughtful reply! I really appreciate how involved you are involved in the Elixir community, makes it a very exciting place to be.

1. This makes sense. Code wanting to do this for a good reason is generally going to look like some sort of job management library. However, given that there's not a consistent pattern for reporting exceptions via the logger, it forces each job library into implementing their own version and keeping it up to date.

I wonder if there's a way we could document how to properly use `crash_reason` so it's easier to implement for folks needing this pattern? The reason I brought it up here is it took me a bit of digging to undercover the ~10 lines of code required to properly generate a `crash_reason`

2. Could you help me understand this a bit more? How does this encourage partial loggers?

[José Valim]

Is this entry in the Logger docs enough:

---

  • :crash_reason - a two-element tuple with the throw/error/exit reason as
    first argument and the stacktrace as second. A throw will always be
    {:nocatch, term}. An error is always an Exception struct. All other entries
    are exits. The console backend ignores this metadata by default but it can
    be useful to other backends, such as the ones that report errors to
    third-party services

---

Or were you thinking about an actual example?

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/03539bff-8cb6-4824-8edc-b602b2bbe167n%40googlegroups.com.

[Jonatan Männchen]

Hey José,

I think that would already be a great improvement.

An example would for sure help as well. (Although all important things are mentioned and one can easily find all necessary information.)

Best,

Jony