[erlang-questions] Differences in code_change callback between gen_server and gen_fsm

[Siri Hansen]

Hi Florian!

The way gen_fsm (and gen_event) is specified is actually the original -
i.e. the code_change should always succeed. The function spec in gen_server
was updated in OTP R15B to allow an error return since this was required
(and had always been used) by supervisor (
https://github.com/erlang/otp/commit/038b9dd3a1f9bdd86cbb83bf3484ab1529d4fca2).
The release_handler was updated at the same time (so even if the supervisor
did use it before, the result would probably not have been too nice if it
actually failed).

Anyway... I guess there would be no harm in updating the spec in gen_fsm to
reflect that an error return is allowed (even if it is not a good idea - it
will fail the complete upgrade and roll back to the old release. A fact
which would have to be stated in the reference manual.) I could write at
ticket for this, but the chance that it would be prioritized within
reasonable time is extremely small. A contribution would help, of course...

When it comes to gen_event, the change would be a bit more complicated.
Errors are not handled at all in the code as it is now.

Regards
/siri


2015-01-06 19:41 GMT+01:00 Florian Waas <flw@REDACTED>:

> In gen_server the callback for code_change is spec’d as
>
>   Module:code_change(OldVsn, State, Extra) -> {ok, NewState} | {error,
> Reason}
>
> in gen_fsm as
>
>   Module:code_change(OldVsn, StateName, StateData, Extra) -> {ok,
> NextStateName, NewStateData}
>
> i.e., upgrades on FSM’s had better succeed? The underlying implementation
> in sys.erl is the same for both and allows for an error case.
> Am I missing some subtlety here?
>
> Thanks,
> -fl.
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150116/bab39c67/attachment.htm>