aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maxim Khutornenko <ma...@apache.org>
Subject Re: Error handling in the aurora client
Date Thu, 02 Oct 2014 21:11:02 GMT
+1 on dumping the stack for unhandled errors as long as they are not
caused by KeyboardInterrupt. That would definitely help
troubleshooting transient errors when --reveal-errors is not a good
option.

On Thu, Oct 2, 2014 at 1:19 PM, David McLaughlin <david@dmclaughlin.com> wrote:
> Because we allow things like hooks, I think it's best to err on the side of
> overly verbose logging by default rather than have to ask client users to
> rerun their command with an extra option just to get a stack trace.
>
>
> On Thu, Oct 2, 2014 at 1:10 PM, Mark Chu-Carroll <mchucarroll@apache.org>
> wrote:
>
>> Can someone explain to me why providing an option to show the stack trace
>> is such a problem?
>>
>> Making our debugging easier shouldn't be an excuse for sloppy tooling.
>> Dumping stacks at users because we didn't get our debugging right shouldn't
>> be acceptable.
>>
>> The specific error here, where we've got a user writing python code in a
>> config file is a special case: we're invoking a python interpretation
>> process for the user, and if that crashes, they expect what they'd get by
>> running the python code manually. But in other places, allowing people to
>> request extra information as an option seems like a reasonable compromise.
>>
>>     -Mark
>>
>>
>>
>>
>>
>> On Thu, Oct 2, 2014 at 3: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
View raw message