Repository navigation
handle_frame swallowing exception? #51
Description
defmodule Foo.Client do
use WebSockex
require Logger
@name __MODULE__
@uri "..."
def child_spec([]) do
%{
id: @name,
start: {@name, :start_link, []},
}
end
def start_link() do
WebSockex.start_link(@uri, @name, :foo, name: @name)
end
def handle_frame({:text, msg}, state) do
Logger.info msg
raise "oops"
end
If something unexpected happens in handle_frame, the exception is completely swallowed - the process crashes but nothing is logged to the console.
Activity
Azolo commentedon Jan 23, 2018
It does catch them so that it can run terminate. Are you manually exiting out of terminate?
pikeas commentedon Jan 23, 2018
Ah, that's probably it - this module hasn't defined
terminate.https://github.com/Azolo/websockex/blob/cb615af5efbe59d1f13e2574d982d5d0a6e6beb4/lib/websockex.ex#L304
I don't see any error handling here - somewhere between
handle_frameandterminateWebSockex is eating the error. How can I get standard Erlang/Elixir behavior, where an unexpected failure loudly crashes the process with a stacktrace?Azolo commentedon Jan 23, 2018
That is the expected behavior. If you haven't defined
terminate/2then it should fail loudly.There's nothing that's written to logger explicitly like
:gen_server(:gen_serverproduces 2 messages) does, but the raised exit message should be a crash message with a stacktrace.Here's the test for it. https://github.com/Azolo/websockex/blob/cb615af5efbe59d1f13e2574d982d5d0a6e6beb4/test/websockex_test.exs#L779-L786
I'll try to reproduce it in a bit, but since the test passed I'm wondering if it's something else in the way that they should be reported that I am missing.
pikeas commentedon Jan 23, 2018
Let me know if you're unable to reproduce and I'll put together a minimal broken example.
pikeas commentedon Jan 23, 2018
Could you clarify what this means? The process is definitely crashing, the crash is caught by a supervisor which restarts the process. If the crash is being properly raised (including stacktrace), what's unexpected is the lack of logging.
From my perspective as a consumer of the library, a quiet crash makes debugging extremely difficult and counterintuitive. For example, it took me about an hour to realize I'd made a mistake in how I was using Poison to decode a response in
handle_frame, which I would have noticed immediately with a standard stacktrace to console.Azolo commentedon Jan 24, 2018
Yes, the supervisor is "eating" the exit and I agree that a logging mechanism is definitely necessary. Normally OTP would receive those exits and create some kind of message. GenServer gets around that limitation by using
:error_loggerand writing the cause and some information to the console.The problem for me is that there are some libraries that depend on
:error_loggerwrapping to flag exits and exceptions so I don't want to just useLogger. When I tried using:error_loggerI couldn't capture it to test it, and after a lot of frustration I took a break. I haven't gotten around to trying it again.In the interim as a workaround, you can do something like:
That(#30) and SSL connections(#1) are why it's not 1.0 release yet.
stocks29 commentedon May 5, 2019
This was really tripping me up. I couldn't figure out why a process I had linked to my socket kept getting a new pid. I'd recommend putting this logging in as the default behavior until this can be properly addressed as you desire.