On Mon, Sep 11, 2017 at 08:49:30PM +1200, Tim Uckun wrote:
> | However, what's great for avoiding straightforward failures becomes a
> | nightmare when your goal is to guarantee that no undefined behaviour
> | happens
>
> It seems to me that if this is your goal other languages are more suitable.
> Erlang for example is famous for it's error handling capability,
> elm guarantees no runtime errors, and some other functional languages can
> be proven mathematically at compile time.
That's not what the author used the term "no undefined behaviour" for;
he referred to the simpler idea of having all possible code paths in the
program flow being handled.
When you have exceptions, you have two problems:
* When they are handled not right at the spot where they are generated, you
- Lose track of the points where they may be generated;
- Have hard time distinguishing between exceptions occured in
different places in the control flow (unless you use super-shallow
and super-wide type hierarchy or encode this information in the
exceptions).
* When new exceptions are added, you have to identify and modify all
places where they're handled.
That's why typically "exception handling" indeed means having try/catch
somewhere at the top level and displaying an error message dialog box
(or a HTTP 500 Internal Error page) to the user which is not error
handling but "avoiding straightforward failures".
As to your particular examples, I'm not familiar with Elm but Erlang
stands out for two reasons:
- It has the so-called "pattern matching" which, coupled with
Erlang's typelessness, allows to implement something which works like
"algebraic types". That is, it's easy to write code which asserts
specific "shapes" and contents of the values at runtime, and crashes
when these expectatiosn are not met. While this is very neat, pretty
much of this is covered by Go's static types.
- It implements the so-called "supervision trees" which allow you to
construct hierarchies of "processes" in which parents get notified
when the children crash, and policies for restarting those processes
which crashed.
While, again, being very neat, their ultimate usefullness is something
disputable: when you have a panic in your Go code, this means you
have a bug, and given the fact Go is a compiled language, this may
mean your whole runtime is an unknown state.
All in all, implementation of supervision trees for Go do exist.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
