[erlang-questions] missing line numbers when gen_statem crashes

[Torben Hoffmann]

Hi Raimo,

That was indeed the case. Was missing a From in a reply tuple.

I wonder what can be done to make all of this more approachable.
My memory of working with the gen_fsm is a much more pleasant one when you
did errors.
I can appreciate that stuffing things into the callback return tuples makes
things harder, but it goes against one of the best things about OTP: it has
always been super easy to find the place in the code where you have messed
up.
With gen_statem I'm not getting the same kind of tranquility as with
gen_server and gen_statem.

I'm wondering if the replies and next_event's should be made explicit calls
in the code.
That way you'd get a line number in your face if you did it wrong.
And it would simplify the callback return structures quite a bit.

So {reply, From, Msg} would have to be done with gen_statem:reply/1,2
exclusively and {next_event, Type, EventContent} would need new functions
gen_statem:next_event/1,2.

If the gen_statem:next_event/1,2 was a thing one could do this without
removing the complex callback return values.
Now that I know what pain error in the callback return values cause when
debugging I would switch to using them exclusively, if the next_event/1,2
functions were available. I value ease of debugging that much.

Cheers,
Torben

On Wed, Jun 13, 2018 at 3:09 PM Raimo Niskanen <
raimo+erlang-questions@REDACTED> wrote:

> On Wed, Jun 13, 2018 at 11:51:31AM +0200, Torben Hoffmann wrote:
> > Hi,
> >
> > I have a crashing gen_statem, but to the best of my knowledge I cannot
> see
> > from the stock error messages which line my gen_statem dies on.
> >
> > I have searched high and low in my console output, but this is the only
> > thing that I could find:
> >
> > =CRASH REPORT==== 13-Jun-2018::11:17:28 ===
> >   crasher:
> >     initial call: eee_sched_shard:init/1
> >     pid: <0.3149.0>
> >     registered_name: []
> >     exception error: {badrecord,trans_opts}
> >       in function  gen_statem:loop_event_actions_list/10 (gen_statem.erl,
> > line 1210)
>
> This is an internal crash in gen_statem - I think i recognize this
> badrecord at line 1210.  Your callback module returns a bad action in the
> actions list, and when gen_statem terminates there is a bug that causes it
> to crash instead, hiding the informative reason.
>
> It might be so that you return an action that is not allowed from a state
> enter call, or simply a not recognized action.
>
> Since the error is "cosmetic" or rather "not in the function", I did not
> patch this in the 20.3 track.  The bad diagnostics error was introduced in
> 20.3 and is corrected in 21.0-rc1 and forwards.
>
>
> >     ancestors: [<0.3148.0>,<0.3114.0>,<0.3107.0>,eee_sched_streams_sup,
> >                   eee_sched_task_sup,eee_sched_sup,<0.2867.0>]
> >     message_queue_len: 0
> >     messages: []
> >     links: [<0.3148.0>]
> >     dictionary: []
> >     trap_exit: false
> >     status: running
> >     heap_size: 6772
> >     stack_size: 27
> >     reductions: 58869
> >   neighbours:
> >
> > I'm about to turn on debug mode, but I don't think that that should be
> the
> > answer to this kind of problem. Line numbers should come out by default.
>
> In this case no line number can be presented since the callback module
> returned a bad term, and it is when processing the return value that the
> error is discovered.  In this case the bad action term should be presented
> in the exception error (which it is from 21.0-rc1).
>
>
> >
> > Cheers,
> > Torben
> > --
> > https://www.linkedin.com/in/torbenhoffmann/
>
>
> --
>
> / Raimo Niskanen, Erlang/OTP, Ericsson AB
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-- 
https://www.linkedin.com/in/torbenhoffmann/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180613/28b0f47b/attachment.htm>