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
José Valim schrieb am Donnerstag, 5. November 2020 um 15:35:42 UTC+1:
> 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?
>
> On Thu, Nov 5, 2020 at 3:14 PM Michael Bianco <[email protected]>
> wrote:
>
>> 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?
>> On Tuesday, November 3, 2020 at 10:09:18 AM UTC-7 [email protected]
>> wrote:
>>
>>> 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
>>>
>>> José Valim schrieb am Montag, 2. November 2020 um 07:55:39 UTC+1:
>>>
>>>> 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 :)
>>>>
>>>>
>>>> On Mon, Nov 2, 2020 at 1:58 AM Michael Bianco <[email protected]>
>>>> wrote:
>>>>
>>>>> 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
>>>>>
>>>>> --
>>>>> 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 [email protected].
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/d/msgid/elixir-lang-core/c89c08e5-9879-414a-b668-0377fc2ab02an%40googlegroups.com
>>>>>
>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/c89c08e5-9879-414a-b668-0377fc2ab02an%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>>
>>>> --
>> 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 [email protected].
>>
> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/elixir-lang-core/03539bff-8cb6-4824-8edc-b602b2bbe167n%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/elixir-lang-core/03539bff-8cb6-4824-8edc-b602b2bbe167n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/76727847-0d4b-441f-9242-33e0547a8054n%40googlegroups.com.
