Elixir in Action Application structure is wrong

is not the same as

So the expected return type of Todo.Application.start/2 should be {:ok, pid()} | {:ok, pid(), state()} | {:error, reason :: term()}, but you’re correct that :ignore is not allowed as return value for the application.

This is not how I defined it, the typespec is your own addition

You are The error message states that ignore return type of the specification is not the subtype of the expected return type for the callback of the application behaviour.

Wher does ignore come from? It’s a part of Supervisor.on_start type.

The Application.start spec in contrast states that valid return values are {:ok, pid()} | {:ok, pid(), state()} | {:error, reason :: term()} (notice the lack of :ignore).

So basically the typespec you provided for Todo.Application.start is incorrect. You could use something like @spec start(Application.start_type, term) :: {:ok, pid} instead.

Ahhh, good point !! My bad!

Ahh, yes, that is correct. I am merely trying to build on the shoulders of titans

This is where I have trouble understanding the issue. If Todo.System.start_link returns the type Supervisor.on_start, then your Todo.Application.start, which returns whatever Todo.System.start_link returns, should return the same.

The error should still be there, as Todo.System.start_link can in theory still return :ignore, thus causing the signature to be different. Am I miss interpreting something?

Sure, go ahead, just don’t credit me with your own work

The return value of the start callback is a subset of possible return values of Supervisor.start_link. As long as Supervisor.start_link returns that subset, everything is fine. Otherwise, the app will fail to start with an error returned a bad value: :ignore.

Keep in mind that dialyzer can’t detect all possible errors. In fact, in my informal estimate, I feel that dialyzer mostly doesn’t catch errors. In this particular example, I’m pretty sure it would miss the case where :ignore is returned, since that situation is triggered by another process (the supervisor process, if our supervisor callback returns :ignore from it’s init).

If everything was running in the same process, the dialyzer would maybe catch a situation where the called function returns a value which is not allowed by the spec.

Edited the original post for the sake of clarity and to not shame you with my horrible work

Wouldn’t something like this be more resilient then?

@impl Application
@spec start(any, any) :: {:ok, pid} | {:error, :ignore | any}
def start(_type, _args) do
  case System.start_link() do
    {:ok, pid}  ->  {:ok, pid}
    :ignore     -> {:error, :ignore}
    error       -> error
  end
end

Or doesn’t it make sense at all?

I personally wouldn’t bother. Returning :ignore from the top-level supervisor is a bug, and so it’s not something I wouldn’t deal with in the code, since either way the app won’t start, and the original error message is IMO clear enough.

As a reader and a fan of your work, and as someone who bought your book to learn Elixir, I believe it would be nice to mention this detail.

Yes, it may be completely useless for someone who already knows Supervisors and GenServers and the interactions with init. It may even be useless for someone who simply copy/pastes your code and runs it.

But for someone like me, who genuinely tries to understand the things that are going on and how to piece everything together using dialyzer in order to make (ever so slightly) more robust apps, such a paragraph could help.

It also prevent idiots like me from creating posts like this

PS: This is just my opinion, you don’t have to agree

Your post asks a perfectly valid question, no need to be hard on yourself.

I’ll keep it in mind for the next edition, thanks!

As the author, I feel I should point out that EiA isn’t a reference book, and so it doesn’t treat every nuance of the language. Even the aspects it talks about aren’t covered in full depth. There’s simply no room for that, but more importantly, I feel that I would lose most of the readers if I went to fine-print detail of every single topic I’m discussing. Thus, some nuances will inevitably be left out, so don’t be surprised if you will have further questions.

On a personal level, the main reason I recommend your book to people around me in work (besides liking it obviously) is the fact I you are so active in this community.

If one of my co workers has a question about your book that I can’t answer, they can always ask the creator for help. And that is priceless.

Happy to hear that!

I think what’s even more important is that we have a nice community here, so different people can chime in with different points of view, like e.g. @LostKobrakai did earlier in this thread by spotting the difference between Application.start and the start callback. This is why I usually advise people to ask their questions on this forum.