zachdaniel

zachdaniel

Creator of Ash

Announcing splode, a tiny library for creating aggregatable and consistent errors for Elixir. Splode is useful for situations when multiple things can go wrong with a given process and you want to combine them into a reasonable response, or when you want consistency in the way you handle errors.

Benefits of using Splode:

  • Errors are regular exceptions. They can be raised, but they can also be combined into an “error class”.
  • Creating a new splode exception captures the stacktrace where it was created. This is extremely useful for situations where you want to illustrate multiple errors.
  • Splode comes with tools to turn arbitrary values into exceptions, and standardizes on a few useful things, like attaching bread_crumbs to errors, storing a path for when errors occur inside of a data structure, and using field and fields for when errors correspond to a field or fields at said path. These conventions allow for writing consistent error handling code across your application.

It is lightly documented at the moment, as its primary reason for existing is to share Ash’s error patterns between Ash and Reactor, and any other packages that we introduce further on down the line.

This is a tiny library that may only be useful in certain situations or for folks who like this pattern, but it is an example of what we’re looking to do with Ash Framework as much as possible going forward, which is to contribute back to the general Elixir ecosystem as much as possible. We want the Elixir ecosystem at large to be able to benefit from our work, regardless of whether or not folks are using Ash :slight_smile:

Check out the getting started guide for more! Get Started with Splode — splode v0.3.1

Showing Posts 1 to 10

zachallaun

zachallaun

Neat! I can think of a few places where this would clean up some of my own code.

A few ergonomics improvements that come to mind:

  1. To ease the transition from existing custom exceptions to Splode and to decrease the API footprint, the existing message callback could be wrapped instead of using a splode_message callback.

  2. Implement a default splode_message (or message if the first suggestion is taken) that, for instance, just inspects the :fields present in the error.

These last two I’m less sure of, but would pretty significantly reduce boilerplate:

  1. Allow module namespaces to be used as implicit error classes when unspecified. For instance:

    defmodule MyApp.Errors do
      use Splode,
        error_classes: [MyApp.Errors.Invalid, MyApp.Errors.Unknown],
        unknown_error: MyApp.Errors.Unknown.Unknown
    end
    
    defmodule MyApp.Errors.Invalid.InvalidThing do
       # Implicitly belongs to the MyApp.Errors.Invalid error class
      use Splode.Error, fields: [:foo, :bar]
    end
    
  2. Define error classes explicitly with use Splode.ErrorClass as opposed to implicitly by including a :errors field. This could inject the splode_message implementation, which it looks like will almost always (or just always?) be the same.

    defmodule MyApp.Errors.Invalid do
      use Splode.ErrorClass
    end
    

Taken all together, before:

defmodule MyApp.Errors do
  use Splode, error_classes: [
    invalid: MyApp.Errors.Invalid,
    unknown: MyApp.Errors.Unknown
  ],
  unknown_error: MyApp.Errors.Unknown.Unknown
end

defmodule MyApp.Errors.Invalid do
  use Splode.Error, fields: [:errors], class: :invalid

  def splode_message(%{errors: errors}) do
    Splode.ErrorClass.error_messages(errors)
  end
end

defmodule MyApp.Errors.Unknown do
  use Splode.Error, fields: [:errors], class: :unknown

  def splode_message(%{errors: errors}) do
    Splode.ErrorClass.error_messages(errors)
  end
end

defmodule MyApp.Errors.Unknown.Unknown do
  use Splode.Error, fields: [:error], class: :unknown

  def splode_message(%{error: error}) do
    if is_binary(error) do
      to_string(error)
    else
      inspect(error)
    end
  end
end

defmodule MyApp.Errors.InvalidArgument do
  use Splode.Error, fields: [:name, :message], class: :invalid

  def splode_message(%{name: name, message: message}) do
    "Invalid argument #{name}: #{message}"
  end
end

And after:

defmodule MyApp.Errors do
  use Splode,
    error_classes: [MyApp.Errors.Invalid, MyApp.Errors.Unknown],
    unknown_error: MyApp.Errors.Unknown.Unknown
end

defmodule MyApp.Errors.Invalid do
  use Splode.ErrorClass
end

defmodule MyApp.Errors.Unknown do
  use Splode.ErrorClass
end

defmodule MyApp.Errors.Unknown.Unknown do
  use Splode.Error, fields: [:error]
end

defmodule MyApp.Errors.InvalidArgument do
  use Splode.Error, fields: [:name, :message]

  def splode_message(%{name: name, message: message}) do
    "Invalid argument #{name}: #{message}"
  end
end
zachdaniel

zachdaniel OP

Creator of Ash

I’m not sure if we can wrap their existing message callback, as the message callback is required for exceptions. As for use Splode.ErrorClass I agree :+1:

zachdaniel

zachdaniel OP

Creator of Ash

I’d prefer not to use module names to implicitly detect error classes. A wrapper macro could be made that does that in someone’s application if they wish.

zachdaniel

zachdaniel OP

Creator of Ash

Also on board with splode_message having a default :+1:

zachallaun

zachallaun

If you were to switch from splode_message to using message, I think you’d need to use @before_compile and defoverridable message: 1. A basic sketch:

defmodule Splode.Error do
  defmacro __using__(opts) do
    quote do
      @before_compile unquote(__MODULE__)
      # mostly everything as before, except don't def message here
    end
  end

  defmacro __before_compile__(env) do
    ensure_def_message =
      if Module.defines?(env, {:message, 1}, :def) do
        quote(do: defoverridable message: 1)
      else
        quote do
          # default impl
        end
      end

    quote do
      unquote(ensure_def_message)

      # the existing def message implementation, except use super instead of calling splode_message
      def message(%{vars: vars} = exception) do
        string = super(exception)
        ...
      end
    end
  end
end
zachdaniel

zachdaniel OP

Creator of Ash

Yeah, that makes sense! I’m down to give that a try :slight_smile: would want to make that change early since it affects end users defining custom extensions. Would you want to PR that change? If not I’ll add it to my list :slight_smile:

zachallaun

zachallaun

I’d like to contribute, but won’t likely have time until mid next week at the earliest. If you want to get to it before then, that’s perfectly fine by me! How about this: I’ll open issues for these suggestions, and whichever of us gets started first can reply to those so that we’re not duplicating effort. :slight_smile:

zachdaniel

zachdaniel OP

Creator of Ash

Perfect :+1:

zachdaniel

zachdaniel OP

Creator of Ash

I’ve made the following changes in 0.2.0:

  1. now you define message/1 instead of splode_message/1
  2. use Splode.ErrorClass can be used now, which adds the errors field and a default message/1 implementation.

As for the other things discussed:

  1. deriving error class from namespaces: I’d personally rather not do this. It takes something explicit and makes it implicit. I imagine users that want to do this can create a custom module to use and make it work that way for them.

  2. adding a default message/1 for any given error. I’m open to this, I just didn’t get around to it. It wouldn’t be a breaking change, so PRs welcome on that front :slight_smile:

zachdaniel

zachdaniel OP

Creator of Ash

0.2.5 adds a .unwrap!/2 function on your modules that use Splode. This allows defining “bang” versions of your functions more simply.

def get_user!(user_id) do
  user_id
  |> get_user()
  |> MyApp.Errors.unwrap!()
end

def get_user(user_id) do
  case Repo.get(user_id) do
    nil ->
      {:error, MyApp.Error.NotFound.exception(resource: User, key: user_id)}
    user ->
      {:ok, user}
  end
end

— All posts loaded —

Where Next? Top

Trending in Announcing Top

wojtekmach
Hey everyone! Req is an HTTP client for Elixir that I’ve been working on for quite some time. There is already a lot of HTTP clients out...
New
handnot2
Samly can be used to enable SAML 2.0 Single Sign On in a Plug/Phoenix application. This library uses Erlang esaml to provide plug enabl...
New
woylie
Flop is an Elixir library that applies filtering, ordering and pagination parameters to your Ecto queries. offset-based pagination with...
New
MRdotB
I needed to reuse React components from my Chrome extension in my Phoenix/LiveView backend. I noticed that for Svelte/Vue, there are live...
New
garrison
Hobbes is a low-level distributed database for the Elixir programming language. Hobbes provides a simple, safe, and scalable storage lay...
New
marciok
Hi there! We created Gust: A task orchestrator inspired by Airflow. For those who have never heard about Aiflow, it’s a Python-based wor...
New
fuelen
Hi all! I want to present a small library which provides a mix task for generating an Entity-Relationship Diagram for Ecto schemas. You...
New

Other Trending Topics Top

mudasobwa
I am happy to introduce the very α version of the new programming language compiled to BEAM. Welcome Cure. It has literally three kille...
New
AstonJ
This showed up on my feed.. anyone heard of it? Just hype? Ox Alpha is a reasoning model designed for coding, sustained ag...
New
sergio
It’s not that it’s vocabulary is too advanced. It’s something worse. I get lost trying to follow even a paragraph written by Claude. It’...
New
sorenone
Today we’re releasing Oban for Python. Not an Oban client in Python. Not a pythonx wrapper embedded in Elixir. Nope, it’s a fully operati...
New
akoutmos
@hugobarauna, Dr. Dimitrios Koutmos (my brother) and I (Alex Koutmos) have been hard at work on writing a book on how you can use Elixir ...
New
pferriby
Introductory paragraph I’ll be looking for a keen junior or someone that has a couple of years experience in the real world (so you’ve be...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews