Handle/render errors or raise exceptions

I think it’s highly personal and situational. My subjective opinion is that if you’re not planning to show the error reason to end-users and if no extra context is required, an atom will suffice. I also don’t like exceptions in general and prefer to deal with error values rather than all this runtime magic. Therefore any expected error is, for me, not exceptional.

thanks @cloudytoday

So how to return the error to the end user (I must include the reason indeed) ?

Again, it absolutely depends on the context. Who is the end user, how much do they need to know, what could they do with this info, how could they recover from the error. In your example, you’re passing the error to the controller, so if the controller has absolutely no way of recovering from this error then you could indeed raise. Or, if it could recover, then you’d have to consider what extra info it will need to do so, and what info it will not need, and how it will handle this info. I don’t think there’s a general answer to this, really depends on the specific case.

Also, I like propagating the error as far as possible so that if there’s a need to raise, all raising happens from within some central point and not in random places (IMO, raising is just outside the responsibility of the “building blocks” functions – their job is to return either {:ok, result} or {:error, reason}).