The current flow of a command's execution runs through the pre_run hook -> run main method -> post_run hook. However, if pre_run or run are interrupted or stopped, post_run is never called.
|
begin |
|
resolved_command.run executed.parsed_arguments, executed.parsed_options |
|
resolved_command.post_run executed.parsed_arguments, executed.parsed_options |
|
rescue ex |
|
resolved_command.on_error ex |
|
end |
This means that post_run is effectively limited to pre_run and run working successfully. So in cases where cleanup needs to be performed before an application exits, your only option is to handle it in pre_run, run or the on_error hook method. That leaves 2 possible options for post_run: to call this method after pre_run/run but not directly require them to exit successfully, or to remove it entirely.
Despite my large advocacy for Cling and its structure, I have never used post_run for any existing CLI applications. It was mostly inspired from Cobra's PostRun methods which operates on a similar premise: postRun is deferred and will always run regardless of the state of the PreRun and Run methods. Assuming none of the methods fail, PostRunE/PostRun is called just before execution ends.
Cling does not differentiate between erroneous and non-erroneous execution methods like Cobra does with "E" suffixed methods because exceptions can be raised at any point of the program making everything erroneous. That means post_run could effectively be changed to always be called as the final part of execution, with any exceptions from it or previous hook methods still being funneled to the on_error hook method.
While this sounds like a clear-cut solution, there are some undefined semantics as to what precedence post_run has in regards to exception handling (or rather, ignoring) which up until this point, has been preceded by the on_error hook method. Would this enforce a stricter exception handling structure? What affects would this impose on existing applications? And most importantly, is it worth it?
The current flow of a command's execution runs through the
pre_runhook ->runmain method ->post_runhook. However, ifpre_runorrunare interrupted or stopped,post_runis never called.cling/src/cling/executor.cr
Lines 61 to 66 in 0dcfb17
This means that
post_runis effectively limited topre_runandrunworking successfully. So in cases where cleanup needs to be performed before an application exits, your only option is to handle it inpre_run,runor theon_errorhook method. That leaves 2 possible options forpost_run: to call this method afterpre_run/runbut not directly require them to exit successfully, or to remove it entirely.Despite my large advocacy for Cling and its structure, I have never used
post_runfor any existing CLI applications. It was mostly inspired from Cobra'sPostRunmethods which operates on a similar premise:postRunis deferred and will always run regardless of the state of thePreRunandRunmethods. Assuming none of the methods fail,PostRunE/PostRunis called just before execution ends.Cling does not differentiate between erroneous and non-erroneous execution methods like Cobra does with "E" suffixed methods because exceptions can be raised at any point of the program making everything erroneous. That means
post_runcould effectively be changed to always be called as the final part of execution, with any exceptions from it or previous hook methods still being funneled to theon_errorhook method.While this sounds like a clear-cut solution, there are some undefined semantics as to what precedence
post_runhas in regards to exception handling (or rather, ignoring) which up until this point, has been preceded by theon_errorhook method. Would this enforce a stricter exception handling structure? What affects would this impose on existing applications? And most importantly, is it worth it?