4 ms·

From memory https://wiki.c2.com/?LetItCrash https://wiki.c2.com/?LetItCrash is a big part of Erlang's (and therefore Elixir's) philosophy. You put everything in

by strken 3y ago

From memory https://wiki.c2.com/?LetItCrash https://wiki.c2.com/?LetItCrash is a big part of Erlang's (and therefore Elixir's) philosophy. You put everything in a process, monitor it with a supervisor, and just crash and let the supervisor recover unless the error is immediately recoverable in the calling code, e.g. trying a second provider or skipping the cache or something.

metadat 3y ago
How do you report on / bubble up what the precise nature of the problem was under this paradigm? E.g. Was it a network issue, content type issue, malformed JSON, unexpected JSON format, etc? I mostly enjoy Go, Python, and Java (in this order), but I must say the self-contained, self-dependency-installing script thing in TFA seems pretty appealing.
- strken 3y ago
  It's been a while since I've touched Phoenix, but from memory it uses separate process pools (meaning lightweight BEAM VM processes) for the http connection, application code, database connections, and probably any other external dependency. A crash in an application process is handled by the http process that sent the work to it. That being said, you return errors in a similar way to other languages if they're expected during the system's operation rather than crashes. Again it's been a while since I had to work with it.
- sb8244 3y ago
  People often take this paradigm too literally, especially if they have not programmed much in Elixir. It is most common to bubble up errors using error tuples, and exceptions are available. Fred Hebert's blog post called "it's about the guarantees" makes this more clear: https://ferd.ca/it-s-about-the-guarantees.html https://ferd.ca/it-s-about-the-guarantees.html
  - throwawaymaths 3y ago
    It's actually a pet peeve of mine that people use error tuples so often in elixir. Honestly most of the time the correct thing is to raise. There really isn't anything you can do anyways, and avoiding the temptation to do something about it and make spaghetti out of the decision tree is worth it.
    - troupo 3y ago
      Many people don't write async code or use supervision trees for most tasks. A lot of code is straightforward synchronous code, so it makes sense not to throw. Once you run it in a task, then it makes less sense to do {:ok, something} on everything
      - throwawaymaths 3y ago
        In what situation are you not supervised? If you're in a phoenix controller, you're very much supervised (even if you didn't write that supervisor) What actually are you going to be doing with that error? Most of the time it gets raised at the end of the error chain resolution.
        troupo 3y ago
        > If you're in a phoenix controller, you're very much supervised (even if you didn't write that supervisor) Yes, but do you want to kill your process and restart? I've been doing quite a bit of LiveView recently, and a thrown error will kill the process and reload the page. I... don't want to do that. > What actually are you going to be doing with that error? Depends on the error :) If it's "record not found", I redirect to a 404. If it's "can't resize image because file format is incorrect" I log it, and display an error message. And so on.
        throwawaymaths 3y ago
        > LiveView recently, and a thrown error will kill the process and reload the page. I... don't want to do that. Ok. That's 100% real and I've run into it myself and been annoyed by it. Probably liveview should do something about that because it's breaking BEAM idioms. > redirect to 404 Raise an error with plug_status set to 404. I believe there's a protocol way of doing it too if you dont own the exception and thus can't add plug_status as a field.
- dbt00 3y ago
  I'm not super familiar with Elixir, but Erlang uses both tuple error responses and panics, it's actually very similar to Go in that way. An erlang process (very similar to a goroutine) can subscribe to another process and will get a message if that process exits with a panic, and can choose what to do with that. The standard implementation is called supervisor, which you can read more about here, the Erlang documentation is very good: https://www.erlang.org/doc/design_principles/sup_princ https://www.erlang.org/doc/design_principles/sup_princ
  - jolux 3y ago
    Elixir is much the same as Erlang in this regard.
- throwawaymaths 3y ago
  If you're in prod, You'll get that information bubbled up to you in sentry when the "process" (not os, green-thread) crashes. If you're in a script, it will come to you as red text (usually) that is generated by the error type. No big deal.

by strken 3y ago

metadat 3y ago

How do you report on / bubble up what the precise nature of the problem was under this paradigm? E.g. Was it a network issue, content type issue, malformed JSON, unexpected JSON format, etc? I mostly enjoy Go, Python, and Java (in this order), but I must say the self-contained, self-dependency-installing script thing in TFA seems pretty appealing.

strken 3y ago
It's been a while since I've touched Phoenix, but from memory it uses separate process pools (meaning lightweight BEAM VM processes) for the http connection, application code, database connections, and probably any other external dependency. A crash in an application process is handled by the http process that sent the work to it. That being said, you return errors in a similar way to other languages if they're expected during the system's operation rather than crashes. Again it's been a while since I had to work with it.
sb8244 3y ago
People often take this paradigm too literally, especially if they have not programmed much in Elixir. It is most common to bubble up errors using error tuples, and exceptions are available. Fred Hebert's blog post called "it's about the guarantees" makes this more clear: https://ferd.ca/it-s-about-the-guarantees.html https://ferd.ca/it-s-about-the-guarantees.html
- throwawaymaths 3y ago
  It's actually a pet peeve of mine that people use error tuples so often in elixir. Honestly most of the time the correct thing is to raise. There really isn't anything you can do anyways, and avoiding the temptation to do something about it and make spaghetti out of the decision tree is worth it.
  - troupo 3y ago
    Many people don't write async code or use supervision trees for most tasks. A lot of code is straightforward synchronous code, so it makes sense not to throw. Once you run it in a task, then it makes less sense to do {:ok, something} on everything
    - throwawaymaths 3y ago
      In what situation are you not supervised? If you're in a phoenix controller, you're very much supervised (even if you didn't write that supervisor) What actually are you going to be doing with that error? Most of the time it gets raised at the end of the error chain resolution.
      - troupo 3y ago
        > If you're in a phoenix controller, you're very much supervised (even if you didn't write that supervisor) Yes, but do you want to kill your process and restart? I've been doing quite a bit of LiveView recently, and a thrown error will kill the process and reload the page. I... don't want to do that. > What actually are you going to be doing with that error? Depends on the error :) If it's "record not found", I redirect to a 404. If it's "can't resize image because file format is incorrect" I log it, and display an error message. And so on.
        throwawaymaths 3y ago
        > LiveView recently, and a thrown error will kill the process and reload the page. I... don't want to do that. Ok. That's 100% real and I've run into it myself and been annoyed by it. Probably liveview should do something about that because it's breaking BEAM idioms. > redirect to 404 Raise an error with plug_status set to 404. I believe there's a protocol way of doing it too if you dont own the exception and thus can't add plug_status as a field.
dbt00 3y ago
I'm not super familiar with Elixir, but Erlang uses both tuple error responses and panics, it's actually very similar to Go in that way. An erlang process (very similar to a goroutine) can subscribe to another process and will get a message if that process exits with a panic, and can choose what to do with that. The standard implementation is called supervisor, which you can read more about here, the Erlang documentation is very good: https://www.erlang.org/doc/design_principles/sup_princ https://www.erlang.org/doc/design_principles/sup_princ
- jolux 3y ago
  Elixir is much the same as Erlang in this regard.
throwawaymaths 3y ago
If you're in prod, You'll get that information bubbled up to you in sentry when the "process" (not os, green-thread) crashes. If you're in a script, it will come to you as red text (usually) that is generated by the error type. No big deal.