Crash back to the wrapper, which then returns the original untouched state and the error.
OvermindDL1
OvermindDL1
svarlet
Thanks for recommending Exceptional. I already had a look at it not so long ago but without context I didn’t give it enough importance.
That helped me quite a bit this time and put on a better track too. Essentially, I refactored a bit my code from something like this:
def user_action(state, param) do
cond do
validate_param() ->
{:error, :reason1}
validate_state() ->
{:error, :reason2}
...
true ->
# the actual logic
end
to
def user_action(state, param) do
param
|> validate_param()
~> validate_state()
~> do_user_action()
end
where validate_xxx function return either the param unchanged or an exception (return, not raise). You could say that it’s not much but the code is much more readable that way. Validators are defined as simple functions and I can now define them outside my module if I need to.
1
svarlet
Now, back to the original topic, what is your usual approach: top down, bottom up? do you represent everything with structs?
0
Qqwy
TypeCheck Core Team
Top-down and bottom-up both work well, and in practice which one I pick depends on the problem (and often I sort of do both at the same time and meet in the middle).
I do not represent everything with structs. In this example, I’d define a %Card{} (with a suit and a rank), a %Player{} (with the amount of money bet thus far, their hand and possibly some other meta-info to link it to an external user) and a %Game{} (which is the high-level State Machine representation, containing a queue of players, the current round of the game, the shuffled deck of hidden cards, and the visible cards that form the street/river or what it is called again in Poker).
Most other things are either atoms (as “poor man’s sum types”) or integers.
0
cdegroot
I’ve had decent success with a module per state and module-defined state, managed by (in this case) a GenServer that basically just forwards calls to state.current_state_module.do_something(state.module_state). For example, my Raft library has a module for “Leader”, “Follower” and “Candidate” and functions transition_from in each one to handle state transitions (with pattern matching on the old state - there is no transition_from(:follower, ...) in the Leader module so that’s automatically an invalid state transition.
It’s simple to test (I usually want to write code in a mix of top-down and bottom-up, mostly guided by tests).
(also, I need to write log compaction for that library so I can call it mostly done ;-))
0