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 19:53:23 GMT
+1 to everything Kevin said.

On Thu, Oct 2, 2014 at 12: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