aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Sweeney <kevi...@apache.org>
Subject Re: Error handling in the aurora client
Date Thu, 02 Oct 2014 19:55:44 GMT
We could also implement Haskell-style error handling like
https://twitter.com/bos31337/status/116372971509121025

On Thu, Oct 2, 2014 at 12:53 PM, David McLaughlin <david@dmclaughlin.com>
wrote:

> +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