[erlang-questions] Is there a way to prevent a crashing process from sending a message to error_logger?

Vans S <>
Fri Sep 15 23:27:23 CEST 2017

Heh sorry for spam.


Seems to do what I need, I will investigate it more! Thanks! 

    On Friday, September 15, 2017 5:25 PM, Vans S <> wrote:

 I tried this, infact the throwaway processes I am spawning are not OTP behaviors but just spawn_linked processes.

1> spawn(fun()-> 1/0 end).<0.63.0>2> =ERROR REPORT==== 15-Sep-2017::17:24:08 ===Error in process <0.63.0> with exit value:{badarith,[{erlang,'/',[1,0],[]}]}
Regardless I get an error report. 

    On Friday, September 15, 2017 3:34 PM, Jachym Holecek <> wrote:

 # Vans S 2017-09-15:
> I am dealing with crashing processes that tend to spam the error logger.
> The crashing processes error reason is being caught and everything is taken care of and 
> logged via the trapping_exits, spawn_linker.
> Still the crashes spam the error_logger.
> I am wondering if there is a way to set specific processes to not send a message upon 
> crash to the error_logger?

Sure, just avoid the proc_lib wrapper (and its direct consumers) and use
plain erlang:spawn_link/X and friends directly -- remember, they're part of
the language for a reason and its perfectly alright to be using them, just
be prepared to ocassionaly dig a bit deeper and learn one obscure corner of
OTP or another every once in a while.

If you wish to use one of the standard OTP behaviours, like gen_server and
such (they're built on top of proc_lib and gen), have a look whether they
provide an 'enter_loop/X' exported function -- that will allow you to still
use the generic logic, but arrange process startup your way, ie. no toplevel
try/catch sending stuff to error_logger. Note that this will not play well
with gen_server's hibernation feature, as return from hibernation will
reinstate proc_lib's toplevel try/catch.

Of course, you could always write your own custom behaviours doing whatever
it takes to integrate well with the rest of your system -- rarely worth the
trouble, but otherwise a perfectly fine thing to do as well.

So much for addressing your specific question. Wider point to make is that
various sources of logging in your system operate at different frequencies
and have varying relevance, blindly routing them all into a single sink is
asking for an operational disaster of one sort or another -- and this is a
mistake users unfortunately seem to run into all too easily. Addresing it
properly takes some effort across all components comprising your system,
no silver bullets there.

    -- Jachym


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170915/58f87e8e/attachment.html>

More information about the erlang-questions mailing list