Return-Path: 
 <dev-return-1655-apmail-aurora-dev-archive=aurora.apache.org@aurora.incubator.apache.org>
X-Original-To: apmail-aurora-dev-archive@minotaur.apache.org
Delivered-To: apmail-aurora-dev-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 6D19B17E05
	for <apmail-aurora-dev-archive@minotaur.apache.org>;
 Thu,  2 Oct 2014 19:40:25 +0000 (UTC)
Received: (qmail 10763 invoked by uid 500); 2 Oct 2014 19:40:25 -0000
Delivered-To: apmail-aurora-dev-archive@aurora.apache.org
Received: (qmail 10723 invoked by uid 500); 2 Oct 2014 19:40:25 -0000
Mailing-List: contact dev-help@aurora.incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@aurora.incubator.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@aurora.incubator.apache.org>
List-Post: <mailto:dev@aurora.incubator.apache.org>
List-Id: <dev.aurora.incubator.apache.org>
Reply-To: dev@aurora.incubator.apache.org
Delivered-To: mailing list dev@aurora.incubator.apache.org
Received: (qmail 10712 invoked by uid 99); 2 Oct 2014 19:40:25 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Oct 2014 19:40:25 +0000
X-ASF-Spam-Status: No, hits=-1998.4 required=5.0
	tests=ALL_TRUSTED,HTML_MESSAGE,RP_MATCHES_RCVD
X-Spam-Check-By: apache.org
Received: from [140.211.11.3] (HELO mail.apache.org) (140.211.11.3)
    by apache.org (qpsmtpd/0.29) with SMTP; Thu, 02 Oct 2014 19:40:02 +0000
Received: (qmail 3374 invoked by uid 99); 2 Oct 2014 19:40:00 -0000
Received: from mail-relay.apache.org (HELO mail-relay.apache.org)
 (140.211.11.15)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Oct 2014 19:40:00 +0000
Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com
 [209.85.212.176])
	by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with
 ESMTPSA id 3A09B1A0042
	for <dev@aurora.incubator.apache.org>; Thu,  2 Oct 2014 19:39:49 +0000 (UTC)
Received: by mail-wi0-f176.google.com with SMTP id hi2so5152658wib.3
        for <dev@aurora.incubator.apache.org>;
 Thu, 02 Oct 2014 12:39:56 -0700 (PDT)
X-Gm-Message-State: 
 ALoCoQly/qjkIOYR02TKXB26nWkkE0j3h0eKkBr/CL6F5l693EOx3A+/dVJDXjLj0taFFbVbF4rh
MIME-Version: 1.0
X-Received: by 10.180.86.33 with SMTP id m1mr6585032wiz.11.1412278796635; Thu,
 02 Oct 2014 12:39:56 -0700 (PDT)
Received: by 10.194.81.33 with HTTP; Thu, 2 Oct 2014 12:39:56 -0700 (PDT)
In-Reply-To: 
 <CAFGkSCm+5jJZPXmEm1=WNz2tSh8Ld+EiO2KYE6Yco=pB_chekQ@mail.gmail.com>
References: 
 <CAFGkSCm+5jJZPXmEm1=WNz2tSh8Ld+EiO2KYE6Yco=pB_chekQ@mail.gmail.com>
Date: Thu, 2 Oct 2014 12:39:56 -0700
Message-ID: 
 <CAGRA8uMObNncAxxkBh-KS5MvZuSxqZRt7TC22t49r-E-wQFy-g@mail.gmail.com>
Subject: Re: Error handling in the aurora client
From: Bill Farner <wfarner@apache.org>
To: "dev@aurora.incubator.apache.org" <dev@aurora.incubator.apache.org>
Content-Type: multipart/alternative; boundary=f46d04428deaff6c4d050475c7c2
X-Virus-Checked: Checked by ClamAV on apache.org

--f46d04428deaff6c4d050475c7c2
Content-Type: text/plain; charset=UTF-8

I'm far more confident in my ability to fix issues for users if they have
easy access to a stack trace when we encounter an unhandled exception.
Here's a great example:

$ python
Python 2.7.5 (default, Mar  9 2014, 22:15:05)
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> try:
...   raise Exception()
... except Exception as e:
...   print e
...

>>> raise Exception()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
Exception

In the first case, i catch the exception and print it out.  Since this
exception has no message, nothing is printed.  A stack trace would point
out the offending call.  Of course we should never throw an exception
without an accompanying message, but we can't control that in libraries we
consume.


-=Bill

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
>

--f46d04428deaff6c4d050475c7c2--