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 <da...@dmclaughlin.com> wrote: > +1 to everything Kevin said. > > On Thu, Oct 2, 2014 at 12:51 PM, Kevin Sweeney > <kswee...@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 < > mchucarr...@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 > > >
