From a5b1ccdb161de17e9dff4055dd841935535b87c3 Mon Sep 17 00:00:00 2001 From: mike-thompson-day8 Date: Sat, 14 Mar 2015 09:47:16 +1100 Subject: [PATCH] Add log-ex middleware. --- src/re_frame/handlers.cljs | 10 +--------- src/re_frame/middleware.cljs | 19 +++++++++++++++++++ 2 files changed, 20 insertions(+), 9 deletions(-) diff --git a/src/re_frame/handlers.cljs b/src/re_frame/handlers.cljs index 7b24aaf..cc8d165 100644 --- a/src/re_frame/handlers.cljs +++ b/src/re_frame/handlers.cljs @@ -65,13 +65,5 @@ handler-fn (lookup-handler event-id)] (if (nil? handler-fn) (warn "re-frame: no event handler registered for: \"" event-id "\". Ignoring.") ;; TODO: make exception - (try - (handler-fn app-db event-v) - (catch :default e - (do - ;; use of a core.async loop seems to completely ruin exception stacks. - ;; So we're going print the exception to the console here, before it gets trashed. - (.error js/console e.stack) - (throw e))))))) - + (handler-fn app-db event-v)))) diff --git a/src/re_frame/middleware.cljs b/src/re_frame/middleware.cljs index 946e9bb..bec3e24 100644 --- a/src/re_frame/middleware.cljs +++ b/src/re_frame/middleware.cljs @@ -35,6 +35,25 @@ (if-not (identical? db new-db) (reset! app-db new-db))))))) +(defn log-ex + "Middleware which catches and prints any handler-generated exceptions to console. + Handlers are called from within a core.async go-loop, and core.async produces + a special kind of hell when in comes to stacktraces. By the time an exception + has passed through a go-loop its stack is mangled beyond repair and you'll + have no idea where the exception was thrown. + So this middleware catches and prints to stacktrace before the core.async sausage + machine has done its work. + " + [handler] + (fn log-ex-handler + [db v] + (try + (handler db v) + (catch :default e ;; ooops, handler threw + (do + (.error js/console e.stack) + (throw e)))))) + (defn debug "Middleware which logs debug information to js/console for each event.