So I’m not sure if this is a reasonable question or not… but has anyone dealt with the case where a defstate fails to start? In my case it might be totally reasonable for a thing to not start, in which case I just don’t want to use it, but there might be other cases where the entire app should stop. Has anyone else thought about/dealt with this stuff?

@lfn3: say we have 3 states A, B and a C. on (mount/start), B failed to start. Are you saying in some case it is ok to ignore this fact, and just use an application with just A and C?

@tolitius: Yeah that’s correct, but some functionality should be disabled when B fails to start.

@lfn3: what is C depends on B?

@tolitius: Seems like the behaviour should be transitive, right? If B fails then C should also fail.

hm.. can you give a use case where this is needed?

transitive failures are not simple

if you don't need the state that could fail (and app is ok with it), can't you just start with "(start-without B)"?

Agreed, but I’m thinking more if B fails to start and C uses B in it’s :start method then transitive-ness will be handled 'auto-magically'.

auto-magic is auto-complex

I am thinking...

The thing is we’d like to try and start with B but if it fails, that’s fine, we just want to have that affect other parts of the application (change routing, for instance)

if B is ok to fail, could it then program this behavior in its start method?

(defn start-b []
  (try ...
    (catch Throwable t
      :dafault-b-value)))

(defstate b :start (start-b))

Yeah that’s where I was headed as well.

another one is:

(mount/start-without "B")
(mount/start)

then if (mount/start) fails, you are still ok

unless you can't really start without B because C depends on it... then:

(mount/start-without "B" "C")
(mount/start)

but this is interesting case. can you create an github issue for this? would be really helpful if you provided a real use case where it is needed

Yeah no problem, I’ll put something together.

great thanks!