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