aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Chu-Carroll <>
Subject Re: Error handling in the aurora client
Date Thu, 02 Oct 2014 20:10:24 GMT
Can someone explain to me why providing an option to show the stack trace
is such a problem?

Making our debugging easier shouldn't be an excuse for sloppy tooling.
Dumping stacks at users because we didn't get our debugging right shouldn't
be acceptable.

The specific error here, where we've got a user writing python code in a
config file is a special case: we're invoking a python interpretation
process for the user, and if that crashes, they expect what they'd get by
running the python code manually. But in other places, allowing people to
request extra information as an option seems like a reasonable compromise.


On Thu, Oct 2, 2014 at 3:51 PM, Kevin Sweeney <>

> We can do both! I think we should dump a stack trace to the console
> whenever we have an unhandled error, as we're not going to be able to debug
> it otherwise.
> We should also strive not to have *any* unhandled errors, but that does not
> mean putting a catch-all exception handler at root, rather it means having
> *specific* error messages for expected error conditions. For example, an
> IOError in a method to read a config file might translate to an error
> message "Unable to read config file: '%s': %s." % (e.filename, e.strerror)
> and a specific exit code. So this might manifest as
> % aurora job create devcluster/web/test/webserver typo.aurora
> ERROR: Unable to read config file 'typo.aurora': No such file or directory.
> % echo $?
> 3
> If the client code (including the support classes) isn't factored to allow
> exception handling like this, it needs to be refactored.
> Also given that the context of this is AURORA-779 I think it's totally
> reasonable to throw a stack trace to someone whose .aurora file raised an
> exception (since they are writing python they should get the tools needed
> to debug python).
> On Thu, Oct 2, 2014 at 12:27 PM, Mark Chu-Carroll <>
> wrote:
> > As we promote clientv2 and deprecate v1, we've come across some issues
> > involving error handling in the v2 client.
> >
> > When there's an unexpected error in clientv1, most of the time, it
> crashes
> > and dumps its stack. Dumping stack is a lousy user experience, but it
> > proves the stack dump, which users can then include in a bug report.
> >
> > The default behavior in clientv2 doesn't dump stack. Instead, it catches
> > the unknown error, and prints out a concise error message, like:
> >
> > Internal error executing command: 'str' object has no attribute 'err_msg'
> >
> >
> > There's no stack dump, so when we get an error report, it's harder for us
> > to track down the cause of the error.
> >
> > Clientv2 does provide a command-line option, "--reveal-errors", which
> > allows errors to be propagated and eventually result in a stack trace.
> >
> > So: should we allow the client to dump stack on error?
> >
> >     -Mark
> >
> --
> Kevin Sweeney
> @kts

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message