From b2576ae4d7bd26a6f69ae26a1c8a83a1b3303f68 Mon Sep 17 00:00:00 2001 From: rktjmp Date: Mon, 3 Jun 2024 06:38:46 +1000 Subject: [PATCH] Improvements to error handling docs (#3282) --- guides/server/error-handling.md | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/guides/server/error-handling.md b/guides/server/error-handling.md index 6411bda77b..f37e411a55 100644 --- a/guides/server/error-handling.md +++ b/guides/server/error-handling.md @@ -27,15 +27,16 @@ However, one may argue that, if the last member of an organization cannot leave it, it may be better to not even show the "Leave" button in the UI when the organization has only one member. -Given the button does not appear in the UI, triggering the "leave" when -the organization has now only one member is an unexpected scenario. This -means we can probably rewrite the code above to: +Given the button does not appear in the UI, triggering the "leave" action when +the organization has only one member is an unexpected scenario. This means we +can rewrite the code above to: true = MyApp.Org.leave(socket.assigns.current_org, member) {:noreply, socket} -If `leave` returns false by any chance, it will just raise. Or you can -even provide a `leave!` function that raises a specific exception: +If `leave` does not return `true`, Elixir will raise a `MatchError` +exception. Or you could provide a `leave!` function that raises a specific +exception: MyApp.Org.leave!(socket.assigns.current_org, member) {:noreply, socket} @@ -64,14 +65,14 @@ check that the user has access to it like this: Repo.get!(organizations_query, params["org_id"]) The code above builds a query that returns all organizations that belongs to -the current user and then validates that the given "org_id" belongs to the -user. If there is no such "org_id" or if the user has no access to it, an -`Ecto.NoResultsError` exception is raised. +the current user and then validates that the given `org_id` belongs to the +user. If there is no such `org_id` or if the user has no access to it, +`Repo.get!` will raise an `Ecto.NoResultsError` exception. During a regular controller request, this exception will be converted to a 404 exception and rendered as a custom error page, as [detailed here](https://hexdocs.pm/phoenix/custom_error_pages.html). -LiveView will react to exceptions in three different ways, depending of +LiveView will react to exceptions in three different ways, depending on where it is in its life-cycle. ### Exceptions during HTTP mount @@ -84,7 +85,7 @@ page by Phoenix error views - exactly how it works with controllers too. ### Exceptions during connected mount If the initial HTTP request succeeds, LiveView will connect to the server -using a stateful connection, typically WebSockets. This spawns a long-running +using a stateful connection, typically a WebSocket. This spawns a long-running lightweight Elixir process on the server, which invokes the `mount` callback and renders an updated version of the page. @@ -98,7 +99,7 @@ fail as if LiveView was not involved in the rendering in the first place. ### Exceptions after connected mount -Once your LiveView is mounted and connected, any error will cause LiveView process +Once your LiveView is mounted and connected, any error will cause the LiveView process to crash and be logged. Once the client notices the error, it will remount the LiveView over the stateful connection, without reloading the page (the exact scenario of the previous subsection). If remounting succeeds, the LiveView goes back to a working