mount

arnout 2016-02-25T08:59:40.000151Z

@lfn3: Isn't this issue application specific, and not something mount could/should support? I read your issue, and I think you give the answer of how to solve it yourself :simple_smile:

(defstate database
  :start (try
           (db/connect ...)
           (catch DbFailException e
             (disable-some-routes-here) ; <--- this is application specific
             :failed)))

lfn3 2016-02-25T09:02:20.000152Z

Sure. But the routes are in a defstate or at least the server is, so then the server needs to be restarted, maybe? I’m perfectly happy with the answer being ‘more documentation’, btw.

lfn3 2016-02-25T09:06:11.000153Z

@arnout: also wrapping every single defstate in a try catch doesn’t seem hugely satisfactory to me.

arnout 2016-02-25T09:45:23.000154Z

@lfn3: True, I would only wrap those that have some special fail logic. I think the server does not need any restarting if you make the routing a little more dynamic (e.g. point to the var of the handler)?

arnout 2016-02-25T09:47:01.000155Z

Even more, maybe the server state can depend on the routing state? That way, the server is started after the routes have been determined?

lfn3 2016-02-25T19:45:20.000157Z

@arnout: Ok, so I put the handlers in a defstate, but then how do I write the (disable-some-routes-here) function? Afaik you can’t supply args to a defstate when doing mount/start. So the handlers get pulled out into like an atom or something? Bear in mind it’s not just disable-some-routes, it’s also disable-some-buttons and turn-off-this-go-loop or whatever.

lfn3 2016-02-25T19:46:37.000158Z

It’d be easier if the handlers defstate could be notified or aware of the faliure of the db defstate, and make decisions appropriately.