Consistent reporting of tracebacks

[dpmatthews]

We need to agree when tracebacks should be reported and then implement the agreed approach across the codebase.

Proposal:

• in debug mode always print a traceback
• in production mode only print a traceback for errors not specifically handled (then users can help us debug unexpected errors)

For an example of inconsistency, create a workflow with a space after a continuation line. cylc validate just returns an error message but cylc run reports a traceback as well.

[kinow]

I'm fine with the proposal. Other command line programs work in a similar way, so +1

[hjoliver]

in production mode only print a traceback for errors not specifically handled

I personally agree with this, but the Cylc 7 pen test report (I think?) suggested users should never see tracebacks as they expose information about the program internals. On the other hand, is that a pointless distinction for a) Python programs, that b) have a --debug option that will print tracebacks (I suppose we could remove --debug option in releases .. but that seems counterproductive - users could then not even help us to debug on request).

[dwsutherland]

in production mode only print a traceback for errors not specifically handled

I personally agree with this, but the Cylc 7 pen test report (I think?) suggested users should never see tracebacks as they expose information about the program internals.

Also it’s an open source project, so anyone with malicious intent can figure out internals.. The only “danger” is runtime settings (if not careful) and site installation/file-structure being exposed.

[hjoliver]

... unless the top-level location of the python library is considered sensitive information that shouldn't be exposed to clients (a web UI user with no local account on the back end would not have easy access to that otherwise)

[hjoliver]

(Tracebacks would require the server to run in debug mode)