How to improve Ecto error handling?

pmjoe

I do like a lot the concept of errors as values, and the pattern match that can be done in Elixir. I’m building an Elixir app right now and I’ve reach the point where I need to interact with the database. I did configured Ecto, and everything is working alright, but I have a big question in my head regards to error handling with Ecto.

Reading Ecto documentation there is very little about error handling, and what I usually see is exceptions being throw most of the times, even on methods like Repo.one, without the exclamation, where it returns the element, nil, or in case of something else, throw an exception.

Maybe I’m trying too hard to catch all the errors, and there are some errors that are really exceptions that should be raised to an upper level? I don’t know, it just feels wrong. I would prefer to handle it, even if it’s just a log entry, and then return from the function with a {:error, ...}. For a moment I thought that the Repo.one was just an exception, but then Repo.all behaves the same.

Any tips? I’m trying to hard to catch these errors? Or Ecto is really too heavy on the exception side? What is your opinion?

2 comments

#ecto_sql

0 351 2

2025-03-09 21:07:49 UTC

Showing Posts 1 to 2

Show Best Posts
Show All (oldest first)
Show All (newest first)

arcanemachine

Ecto documentation is pretty old in a lot of places, and I wouldn’t necessarily take it as a best practices guide for my application programming in general. It just covers so many use cases that sometimes some contrived examples would be needed.

I would probably stick to error handling as needed. Use with blocks to handle your happy path cases, then use the fallback controller (if you’re using Phoenix) to handle common errors, e.g. changeset errors. (If you’re not familiar, this is what the Phoenix generators spit out, I believe it’s the phx.gen.html generators that would have examples). For one-off “errors”, just use a custom with...else statement to handle that specific error. Then add common errors to the fallback controller as needed.

The bang functions can be useful in certain circumstances. For example, if using Repo.one! in a controller, that can automatically return 404 in a Phoenix controller. (I believe this is the default Phoenix behavior, my Phoenix is a little rusty ATM.)

Post #1

LostKobrakai

My perspective is the Repos job is executing queries and dealing with resulting data. Any failures of the way queries or results are shaped like only produce exceptions on bang functions.

Repo however expects a working connection to the db. So any problems with that are indeed exceptional and therefore raise exceptions. Problems with connections should be dealt with at the level of connection handling / the db pool. Not at the level of some code trying to run a query.

Post #2

— All posts loaded —