[erlang-questions] Nested Case Statements v.s. multiple functions

[Richard A. O'Keefe]

On 27/09/17 4:43 AM, code wiget wrote:
> Thank you all for your replies, I went ahead and changed my function
> names and added guards, and it now looks far cleaner.
>
> One thing that I keep seeing in this thread though is some variant
> of*/“crash early, crash often,”/* and this is a little troubling. What
> if you are writing a program that is receiving a messages and has a
> queue awaiting action? If the program dies, those messages will be lost,
> and if the calling processes made ‘casts’ then those messages won’t ever
> be delivered or processed. Also, it takes a bit of time for the
> supervisor to re-initialize the process, and this could be bad.

Factor it this way.

You have a finite state automaton that is responding to the messages
in the queue.  You want to be certain that that process is extremely
unlikely to crash.  So you have a part which is just concerned with
managing the protocol, and it delegates the actions.

It delegates the actions to worker processes.  If one of those
crashes, that's an outcome that can be caught and acted on by the
protocol manager.  Again, if one of them goes into an infinite
loop, or waits forever, that's not technically a crash, but it is
just as effective at stopping response to the queue.  So you want
the work in another process so that you can wait for the result or
a timeout, and if there's a timeout, you can treat this as a
"result late" error.

An advantage of this is that if there are work items in the queue
they can be processed in parallel.  But fault isolation is the
biggie.

The time taken to start a new worker need not be all that large.