Re: Proposed TraceBack Change
- Posted by Matt Lewis <matthewwalkerlewis at gmail.com> Apr 18, 2007
- 449 views
Pete Lomax wrote: > > Matt Lewis wrote: > > > > > > In the current trace back (both in be_rterror.c and error.e) the path + > > file name length is truncated to 99 chars. Does anyone have any objection > > to raising this limit? > I will be *strongly* against this, unless you do one thing: > Wherever you output a full path + file name, make it a *FULL* path! I'm curious why you're strongly against this. Maybe I'm just not understanding you. The current behavior seems to depend upon how the interpreter is invoked. If you rely on your PATH, then it will use paths in the traceback. If you specify the interpreter directly, it appears to use file names only. I'm not certain as to how/where this is done--just haven't looked into it. My concern was that when you get an error, it would display most of the path for a really long path, but might cut off part of it. > Regards, > Pete > PS actually, I cannot now reproduce the sort of annoying problem I've often > had, eg looking in C:\test when it should be C:\test\bench, or looking in > C:\test\bench\bench > when it should just be C:\test\bench, but it has bit me more than once - > because > line 1 just says "test.exw" or "bench\test.exw", which may not [even] marry > with location of ex.err, sometimes. (Erm maybe this bites harder after a > chdir() > call within the app?) Fixing this is a separate issue from the one to which I refer (basically, I was doing stuff in a path that was somewhere around 120 chars). Anyways, it's already committed. :P Matt