|
|
|
|
|
|
by scatterhead
1314 days ago
|
|
|
> What is a Golang person... a Goist? A Goer (hehe, Monty Python). Since I am a goer, I'll use Goist here. Gopher. > Is it the Erlang or the Elixir folks to just say, paraphrased, "let it die"? That sounds like panic. When the Erlang folks say that, they're talking about letting a process die. The rest of the application is in different processes and doesn't get taken down. So the offending process can be rebooted and operations can continue. > if err != nil { return err } // put it on one line. It's clean and natural. Oh.. erm... well that's explicitly not letting it die. That's returning it and forcing it to be manually "dealt with", as you put it. It seems like you're contradicting yourself. Also, the article explains that returning without context is often a bad idea. |
|
|
Now I know what being old means. It means you can make references to things, and younger people will completely overlook them.
Of course I can do a small bit of internet search to get the answer to my rhetorical question. But I thought (wrongly) that it would be more entertaining to make a Monty Python reference. "Is your wife a goer? Know what I mean?"
> that's explicitly not letting it die. That's returning it and forcing it to be manually "dealt with"
That is letting it die in the sense of not handling the error locally. It is allowing the failure to go upstream, and either assuming the caller will handle it, blow up, or further pass it up.
> Erlang
As I understand it, the supervisor processes ensure that the workers are up and running. If one dies, it gets restarted within the constrants of failure count limits and such.
Instead of handling errors, you can choose to allow a failure to blow up the "process" (it's not a full OS process, I believe) and be comforted in the knowledge that your process will be restarted.
If you look at many business processes (take web app activities for example), you see that failures don't get resolved in perfect tidy fashion. Instead of trying to handle the multitude of possible failure cases, you just accept that many failures cannot be recovered from. You just let it silently die, and you maybe provide a general "sorry, try again" message to the user.
That is acceptable in a lot of cases, especially when it is virtually impossible to properly handle all failure cases gracefully. Imagine if a user were uploading an image to a web app, and CopyFile() failed. How would you handle that? Would you tell the user, "Sorry, we got your upload, but we couldn't put it in its proper place, so it failed. Try again."? Or could you let it "blow up" and just tell the user, "upload failed; try again".
Now imagine you try to handle failure cases and properly report them all upstream. Now if you write tests, your tests must test for the success path and multitudes of possible failure cases and resolutions. In practice, this just is not done (outside special high risk scenarios like commercial flight and such).