Hi,
If a template calls a function that crashes, e.g. with a function_clause
or a case_clause error, that error is currently squelched, the http
request is terminated, and the only thing visible in the logs is
something like
[error] Error in process <0.1337.0> on node 'appname@host' with exit
value:
{{case_clause,closed},[{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,529}]}]}
meaning that cowboy doesn't have any way to handle this case (which
makes sense, I guess).
Now, if, for example, errors from
boss_web_controller_render:render_with_template are caught in
boss_web_controller_render:render_view, it is possible to intercept such
errors and handle them, something along the lines of
try render_with_template(Controller, Template, AppInfo, RequestContext,
Variables, Headers, Req, BossFlash,
SessionData, Module, TemplateAdapter)
catch error:Error ->
Trace = erlang:get_stacktrace(),
lager:error(
"Runtime error while rendering template ~p: ~p, stack: ~p",
[Template, Error, Trace]),
render_error(Error, Trace, AppInfo, RequestContext)
end;
So far, everything is fine, but I wonder if this is not a somewhat
deeper architectural question. My erlang knowledge is limited, but
AFAICT, what happens here is that the boss process that handles
rendering (boss_web?) crashes and the cowboy process doesn't have any
way to clean up. Are there other places where a boss application can
crash and cause similar problems, and should such crashes be handled in
a more generic way somewhere else? Thoughts?
Thanks,
- Fredrik
--
You received this message because you are subscribed to the Google Groups
"ChicagoBoss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
Visit this group at http://groups.google.com/group/chicagoboss.
To view this discussion on the web visit
https://groups.google.com/d/msgid/chicagoboss/ygnma9euaofx.fsf%40rubin.ifi.uio.no.
For more options, visit https://groups.google.com/groups/opt_out.
