aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Sweeney <kswee...@twitter.com.INVALID>
Subject Re: Error handling in the aurora client
Date Thu, 02 Oct 2014 19:51:17 GMT
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