zachdaniel
Splode - Aggregatable and consistent errors for Elixir
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
pathfor when errors occur inside of a data structure, and usingfieldandfieldsfor 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 ![]()
Check out the getting started guide for more! Get Started with Splode — splode v0.1.1
Most Liked
zachdaniel
I’ve made the following changes in 0.2.0:
- now you define
message/1instead ofsplode_message/1 use Splode.ErrorClasscan be used now, which adds theerrorsfield and a defaultmessage/1implementation.
As for the other things discussed:
-
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
useand make it work that way for them. -
adding a default
message/1for 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
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
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. ![]()







