On Thu, Jun 17, 2010 at 2:05 AM, Andreas Fritiofson <andreas.fritiof...@gmail.com> wrote: > On Thu, Jun 17, 2010 at 12:30 AM, Øyvind Harboe <oyvind.har...@zylin.com> > wrote: >> On Wed, Jun 16, 2010 at 11:40 PM, Andreas Fritiofson >> <andreas.fritiof...@gmail.com> wrote: >>> >>> The stack trace provides no valuable information to the user for >>> interactive commands. >> >> What about nested proc's? >> > > You mean when calling user defined tcl procedures calling other tcl > procedures that fails? > > My guess is the *user* doesn't particularly care about the chain of > events leading up to the fault. It's probably due to either misuse of > the first procedure, in which case the user is fully aware of what the > called procedure was, or a bug in one of the following. If it's a bug > it calls for debugging, a job for a *developer* (might of course be > the same person with another hat). The developer could flip the debug > level switch and see the stack trace as previously. > > Then on the other hand I don't get a stack trace when a shell script > in multiple nesting levels fails, and I'm not very bothered about > that. > > I think the current error messages do more harm than good in the > majority of cases. If there's a better solution I'm open to > suggestions.
I agree that the current error messages are ugly, but I don't agree that we should not print file and line # of e.g. syntax error. However, we may be able to address this in a more fine grained fashion than simply turning the stack traces on and off. Perhaps you could post some examples and show what parts of the stack trace that is useful and what's just (debug) noise? > > /Andreas > -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
