aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David McLaughlin <da...@dmclaughlin.com>
Subject Re: Error handling in the aurora client
Date Thu, 02 Oct 2014 20:19:58 GMT
Because we allow things like hooks, I think it's best to err on the side of
overly verbose logging by default rather than have to ask client users to
rerun their command with an extra option just to get a stack trace.


On Thu, Oct 2, 2014 at 1:10 PM, Mark Chu-Carroll <mchucarroll@apache.org>
wrote:

> 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.
>
>     -Mark
>
>
>
>
>
> On Thu, Oct 2, 2014 at 3:51 PM, Kevin Sweeney <ksweeney@twitter.com.invalid
> >
> wrote:
>
> > 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 <
> mchucarroll@apache.org>
> > 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
> >
>

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