Re: Error handling in the aurora client

2014-10-03 Thread Brian Wickman
+1 as well. On Fri, Oct 3, 2014 at 9:13 AM, Maxim Khutornenko wrote: > +1 on that. Hides away the ugliness yet more accessible than searching > through client logs. > > On Fri, Oct 3, 2014 at 5:51 AM, Mark Chu-Carroll > wrote: > > I like the proposal from John. Any objections to implementing th

Re: Error handling in the aurora client

2014-10-03 Thread Bill Farner
Works for me. On Friday, October 3, 2014, Brian Wickman wrote: > +1 as well. > > On Fri, Oct 3, 2014 at 9:13 AM, Maxim Khutornenko > wrote: > > > +1 on that. Hides away the ugliness yet more accessible than searching > > through client logs. > > > > On Fri, Oct 3, 2014 at 5:51 AM, Mark Chu-Carr

Re: Error handling in the aurora client

2014-10-03 Thread Maxim Khutornenko
+1 on that. Hides away the ugliness yet more accessible than searching through client logs. On Fri, Oct 3, 2014 at 5:51 AM, Mark Chu-Carroll wrote: > I like the proposal from John. Any objections to implementing that? > > -Mark > > On Fri, Oct 3, 2014 at 2:23 AM, Joshua Cohen > wrote: > >>

Re: Error handling in the aurora client

2014-10-03 Thread Mark Chu-Carroll
I like the proposal from John. Any objections to implementing that? -Mark On Fri, Oct 3, 2014 at 2:23 AM, Joshua Cohen wrote: > Came here to make the same suggestion John makes. What if we present > friendly error messages to the user, but write stack traces to a log file > that the user

Re: Error handling in the aurora client

2014-10-02 Thread Joshua Cohen
Came here to make the same suggestion John makes. What if we present friendly error messages to the user, but write stack traces to a log file that the user can upload in the event of unexpected/unhandled exceptions. IMO the reason for not wanting to rely on users re-running commands with a verbose

Re: Error handling in the aurora client

2014-10-02 Thread John Sirois
Drive-by, but this has been on my mind with pants as well: How about the current behavior but add a pill, ie: [ref:232e86a2d] Internal error executing command: 'str' object has no attribute 'err_msg' The full backtrace goes off to a file in the user's home dir somewhere and then you can ask them

Re: Error handling in the aurora client

2014-10-02 Thread Maxim Khutornenko
+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 wrote: > Because we allow things like hooks, I

Re: Error handling in the aurora client

2014-10-02 Thread David McLaughlin
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 wrote: > Can someone explain

Re: Error handling in the aurora client

2014-10-02 Thread Mark Chu-Carroll
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

Re: Error handling in the aurora client

2014-10-02 Thread Kevin Sweeney
We could also implement Haskell-style error handling like https://twitter.com/bos31337/status/116372971509121025 On Thu, Oct 2, 2014 at 12:53 PM, David McLaughlin wrote: > +1 to everything Kevin said. > > On Thu, Oct 2, 2014 at 12:51 PM, Kevin Sweeney > > wrote: > > > We can do both! I think we

Re: Error handling in the aurora client

2014-10-02 Thread David McLaughlin
+1 to everything Kevin said. On Thu, Oct 2, 2014 at 12:51 PM, Kevin Sweeney 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* unhan

Re: Error handling in the aurora client

2014-10-02 Thread Kevin Sweeney
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 me

Re: Error handling in the aurora client

2014-10-02 Thread Kevin Sweeney
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 me

Re: Error handling in the aurora client

2014-10-02 Thread Bill Farner
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 "hel