Fork me on GitHub
#mount
<
2016-02-25
>
arnout08:02:40

@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)))

lfn309:02:20

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.

lfn309:02:11

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

arnout09:02:23

@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)?

arnout09:02:01

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

lfn319:02:20

@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.

lfn319:02:37

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