Flush error_logger before capturing #5280
Conversation
| processes. It is possible to ensure explicit log messages from other | ||
| processes are captured by waiting for their exit or monitor | ||
| signal. This does not guarantee to capture VM generated log messages | ||
| when a process spawned using a `spawn` BIF does not catch an exception. |
There was a problem hiding this comment.
I've definitely heard the term BIF used in erlang docs, but don't think I've encountered it in the Elixir docs so I've assumed it wasn't really a term used by Elixir. Should this be Kernel.spawn or similar instead?
|
👍 Thanks, @fishcakez! |
| when a process is spawned using a low level `Kernel` spawn function (e.g. | ||
| `Kernel.spawn/1`) does not catch an exception. A `Task`, or other OTP | ||
| process, will send explicit logs that are sent before its exit or monitor | ||
| signal and will not cause VM generated log messages. |
There was a problem hiding this comment.
@myronmarston is this description clearer?
There was a problem hiding this comment.
It's better, but I think the "does not catch an exception" part is a bit confusing. This spawned process does not catch an exception, but I don't think it's what you mean:
spawn(fn -> :ok end)Maybe "raises an unhandled exception" or just "crashes" or something similar would be clearer?
| when a process is spawned using a low level `Kernel` spawn function (e.g. | ||
| `Kernel.spawn/1`) raises an exception that isn't rescued or a thow that | ||
| isn't caught. A `Task`, orther OTP process, will send explicit logs that | ||
| are sent before its exit or monitor signal and will not cause VM generated |
There was a problem hiding this comment.
@myronmarston how about this rewording?
There was a problem hiding this comment.
Much clearer. I found a couple more grammar/spelling issues. I'm happy with it once those are addressed :).
| processes are captured by waiting for their exit or monitor | ||
| signal. This does not guarantee to capture VM generated log messages | ||
| when a process is spawned using a low level `Kernel` spawn function (e.g. | ||
| `Kernel.spawn/1`) raises an exception that isn't rescued or a thow that |
|
Please don't squash/merge before #5262 and please do backport to |
| processes. It is possible to ensure explicit log messages from other | ||
| processes are captured by waiting for their exit or monitor | ||
| signal. This does not guarantee to capture VM generated log messages | ||
| when a process is spawned using a low level `Kernel` spawn function (e.g. |
There was a problem hiding this comment.
Grammatically, "process is spawned...raises" is awkward. "process that is spawned...raises" reads better.
| signal. This does not guarantee to capture VM generated log messages | ||
| when a process is spawned using a low level `Kernel` spawn function (e.g. | ||
| `Kernel.spawn/1`) raises an exception that isn't rescued or a throw that | ||
| isn't caught. A `Task`, orther OTP process, will send explicit logs that |
|
English is my native language ❤️ |
|
❤️ 💚 💙 💛 💜 |
Signed-off-by: José Valim <jose.valim@plataformatec.com.br>
/cc @myronmarston