"Catch-all" error handling in LiveView

The essential problem with a catch-all in liveviews is the fact that in context of idiomatic state, your liveview will be in an invalid state once you hit the error. In contrast a controller fallback_action is not a state change, but a different pipeline for rendering the error response.

The easiest way I see this done is having some custom attributes for rendering the error flash, and in the catch-all statement, instead of letting the process crash, redirect to the same liveview with the passing of error as a parameter, this way you can ensure that the liveview will be in a clear state and you have the error on your hand.

Okay, so put another way… forget everything about fallback controllers and whatnot.

When a LiveView process crashes, is there any good way to get crash information (the exception) to the client? I suspect the new LiveView process has no idea about the prior one, but does the client itself? It seems like somewhere, something at least can know the two processes were associated.

If this were possible, it would actually solve most of the issues. You could have a helper function at essentially knows how to handle certain kinds of exceptions and display information in a flash, or a modal, or whatever. That doesn’t really matter. The trick is… can I get the exception data to the client?

I feel like all the pieces are definitely in place. Even if the JavaScript has to query something like, “Hey, this was my last process ID, did it leave an error?” That could be handled on_mount during remounting and then do whatever it needs to do to show whatever UI piece delivers that data to the user.

What we do is wrap mount/handle_* functions in undead which catches errors, logs them to Sentry, and shows the user an error page (if the error was on mount, to avoid loops) or a flash message with a description of the error and the option to submit feedback (which automatically includes a link to the Sentry error log) bonfire_ui_common/lib/ui_common.ex at main · bonfire-networks/bonfire_ui_common · GitHub

Looking through the code, this is essentially what I want to do… only without having to constantly wrap things in something like undead/3. That seems like that is going to add a whole lot of noise all over the place and it’s still opt-in.

The developers have to do this all over the place, yes?

If forced, I would probably take some kind of middle ground where I have specialized LiveView functions for handling common scenarios like authorization and fetching resources where I expect errors and then handle them appropriately, but even then it ends up being a lot more ceremony than just having something generic that’s there to catch errors that it understands.

I’m sure it could be done transparently with macros but there’s something to be said for opt-in explicitness, but it’s not as much of a hassle as you expect, instead of wrapping all LiveView function bodies in undead, we do this:

  def handle_event(action, attrs, socket), do: Bonfire.UI.Common.LiveHandlers.handle_event(action, attrs, socket, __MODULE__, &do_handle_event/3)

and define do_handle_event/3 for view or component-specific logic, whilst LiveHandlers module takes care of error handling (and as a bonus also handles or delegates events that are used in more than one view or component).

There is, but I sometimes feel like “explicitness” becomes a bit of a cop-out. While Elixir and Phoenix are a really nice step back from the world of Ruby (which I still love, admittedly) in that sense, there are times when a pattern is so common that you just don’t want to have to pepper it all over the place.

One man’s explicitness is another man’s boilerplate! Haha.

Even the macro path isn’t great to me because I’d have to replace common conventions with a bunch of macros. That could actually work, but… I don’t love it. Actually, maybe I do love it. (I’m gonna be honest, when people are preaching to be careful about the use of meta programming, I kinda feel like someone is secretly looking at me.)

I probably need to dig into the LiveView lifecycle and see if I can cook something up. But I just had an idea about macros I have to look into. Thanks for the input either way. I dunno exactly where to take this, but this conversation has given me more options than I started with.

Yeah I don’t disagree. Actually just realised this might be a great job for GitHub - arjan/decorator: Function decorators for Elixir · GitHub so it’s still explicit but less boilerplaty.

This is excellent. Thank you for sharing this. Although you might be the person I blame if I’m up later than I’d planned, lol.

Just came across this old thread and wanted to notify you that I’ve since implemented it in a transparent way that doesn’t require repeating code in views or live components, by defining it in our Web module with @before_compile at bonfire_ui_common/lib/web.ex at main · bonfire-networks/bonfire_ui_common · GitHub and then bonfire_ui_common/lib/web.ex at main · bonfire-networks/bonfire_ui_common · GitHub

  defp live_mount_before_compile(env) do
    if Module.defines?(env.module, {:mount, 3}) do
      quote do
        defoverridable mount: 3

        def mount(params, session, socket) do
          undead_mount(socket, fn ->
            super(params, session, socket)
          end)
        end
      end
    end
  end