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