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.

Reply via email to