4 ms·

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 actua

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.
  - troupo 3y ago
    > Probably liveview should do something about that because it's breaking BEAM idioms. It really doesn't. It's the `one_to_one` restart strategy for supervision. > Raise an error with plug_status set to 404. Honestly, first time I've heard about it :) It's somewhat well hidden in the docs I think. But 404 is just one of possible responses. I might want to redirect instead. Auth errors should be also handled by redirects. And so on. Not everything is an exception for the framework supervisor to handle through custom fields.
    - throwawaymaths 3y ago
      It's a protocol. You can set up your custom action (including redirects) here: https://hexdocs.pm/plug/Plug.Exception.html#actions/1 https://hexdocs.pm/plug/Plug.Exception.html#actions/1 This is how phoenix does those fancy error reports in dev (but not prod) > Probably liveview should do something about that because it's breaking BEAM idioms. Actually now that I think about it, failable actions should probably be wrapped in a task. It's not hard for the liveview to subscribe to task failures and bubble it up to the user as a flash. Not doing so is breaking processes-as-failure-domains concept. The phoenix liveview documentation should probably hoist that sort of guidance to the top and put flashing lights around it.
      - troupo 3y ago
        > You can set up your custom action (including redirects) here: But why would I do that for things that 100% predictable, can and will happen in specific flows? > failable actions should probably be wrapped in a task. It's not hard for the liveview to subscribe to task failures and bubble it up to the user as a flash. How does LiveView know an action is failable? What you propose is akin to trying to solving the halting problem :) Also, not all failures need to be propagated to the user as a flash: - an auth failure should result in a redirect, not a flash - a record not found failure could result in an in-place 404, a redirect to a 404, a redirect to a search page, in a cache lookup etc. - validation errors should be propagated to the form and displayed inline, not as a flash and so on. There are many failure modes and there are just as many recovery modes, the vast majority of which entirely depend on the business logic of your app that LiveView has no idea about
        throwawaymaths 3y ago
        > How does LiveView know an action is failable? Sorry I should have been more clear. You should wrap failable actions in a task if you're calling it from a liveview. > an auth failure should result in a redirect, not a flash That should happen before the socket plug and perform the redirect before even the websocket upgrade.
sb8244 3y ago
Return the error to my user so they can at least see what went wrong with their request (assuming the errors are built to be user facing). The idea of hiding information from the user, just for me to get it from bug tracking and support tickets is not something I could jive with.
- throwawaymaths 3y ago
  > assuming the errors are built to be user facing Most errors are not? Suppose you get KeyError. Is that information useful to the user?
  - sb8244 3y ago
    I'd say most errors I handle are user facing in some way. The specific error (going to say in response to API given the article) you gave would likely be returned through the system as API response error tuple. The parts of call stack higher up could determine if they want to show the error or swallow it. If it's a generic KeyError or MatchError, there's a 0% chance anything outside of the immediate call site could handle the error.

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.
- troupo 3y ago
  > Probably liveview should do something about that because it's breaking BEAM idioms. It really doesn't. It's the `one_to_one` restart strategy for supervision. > Raise an error with plug_status set to 404. Honestly, first time I've heard about it :) It's somewhat well hidden in the docs I think. But 404 is just one of possible responses. I might want to redirect instead. Auth errors should be also handled by redirects. And so on. Not everything is an exception for the framework supervisor to handle through custom fields.
  - throwawaymaths 3y ago
    It's a protocol. You can set up your custom action (including redirects) here: https://hexdocs.pm/plug/Plug.Exception.html#actions/1 https://hexdocs.pm/plug/Plug.Exception.html#actions/1 This is how phoenix does those fancy error reports in dev (but not prod) > Probably liveview should do something about that because it's breaking BEAM idioms. Actually now that I think about it, failable actions should probably be wrapped in a task. It's not hard for the liveview to subscribe to task failures and bubble it up to the user as a flash. Not doing so is breaking processes-as-failure-domains concept. The phoenix liveview documentation should probably hoist that sort of guidance to the top and put flashing lights around it.
    - troupo 3y ago
      > You can set up your custom action (including redirects) here: But why would I do that for things that 100% predictable, can and will happen in specific flows? > failable actions should probably be wrapped in a task. It's not hard for the liveview to subscribe to task failures and bubble it up to the user as a flash. How does LiveView know an action is failable? What you propose is akin to trying to solving the halting problem :) Also, not all failures need to be propagated to the user as a flash: - an auth failure should result in a redirect, not a flash - a record not found failure could result in an in-place 404, a redirect to a 404, a redirect to a search page, in a cache lookup etc. - validation errors should be propagated to the form and displayed inline, not as a flash and so on. There are many failure modes and there are just as many recovery modes, the vast majority of which entirely depend on the business logic of your app that LiveView has no idea about
      - throwawaymaths 3y ago
        > How does LiveView know an action is failable? Sorry I should have been more clear. You should wrap failable actions in a task if you're calling it from a liveview. > an auth failure should result in a redirect, not a flash That should happen before the socket plug and perform the redirect before even the websocket upgrade.

sb8244 3y ago

Return the error to my user so they can at least see what went wrong with their request (assuming the errors are built to be user facing). The idea of hiding information from the user, just for me to get it from bug tracking and support tickets is not something I could jive with.

throwawaymaths 3y ago
> assuming the errors are built to be user facing Most errors are not? Suppose you get KeyError. Is that information useful to the user?
- sb8244 3y ago
  I'd say most errors I handle are user facing in some way. The specific error (going to say in response to API given the article) you gave would likely be returned through the system as API response error tuple. The parts of call stack higher up could determine if they want to show the error or swallow it. If it's a generic KeyError or MatchError, there's a 0% chance anything outside of the immediate call site could handle the error.