Personally, I would not place much priority on the visual aesthetics of error reports. I sympathize, but I have not thought through the issues so I am not even able to comment on whether this is a reasonable suggestion.
And, it's not like I do not have enough other things to deal with. That said: if you were having complex problems in the past, it might have been a consequence of the error latent expression being set in your context. -- Raul On Tue, Feb 12, 2013 at 2:16 PM, Don Guinn <[email protected]> wrote: > Went back and played with debug with try. and they seem to be working as > one would expect. When try. first came out I had a lot of trouble with > debug on definitions using try. so I have avoided debug on definitions with > try. in them. Seems that whatever was going on was fixed or I had just > messed up and blamed it on try. with debug. > > On the other point about wanting a new signal error. Let me explain. I have > always felt that (13!:8) didn't work properly. But fixing it may break > something else, so I suggested a new signal error. Here is a silly verb to > illustrate my concern: > > f=:4 : 0 > > try. > > a=.i.#x > > b=.x+a+y > > c=.>:b > > catch. > > m=.(13!:11)'' > > ('Hey dummy, ',>(<:m){(9!:8)'') (13!:8) m > > end. > > ) > > > 1 2 f 1 2 3 > > Error Number: 9 > > |Hey dummy, length error > > | ('Hey dummy, ',>(<:m){(9!:8)'') (13!:8)m > > > The last line is useless. It would be better if the error was displayed as: > > > 1 2 f 1 2 3 > > Error Number: 9 > > |Hey dummy, length error > > | 1 2 f 1 2 3 > > > That would look more like how errors are displayed for primitives: > > > 1 2 + 1 2 3 > > |length error > > | 1 2 +1 2 3 > > > I really don't care to see the line that generates the error message, I > would rather see the line which caused the error. Just like in primitives > errors. > > > > On Mon, Feb 11, 2013 at 10:08 AM, Raul Miller <[email protected]> wrote: > >> Are you saying 13!:0+1 introduces problems with try. and error display? If >> so, could you give some examples? >> >> Thanks, >> >> -- >> Raul >> >> On Monday, February 11, 2013, Don Guinn <[email protected]> wrote: >> > I've done that, but then when errors occur the output gets really messy. >> > And I get confused when using try. . >> > >> > On Mon, Feb 11, 2013 at 9:03 AM, Raul Miller <[email protected]> >> wrote: >> > >> >> Or, make debug be active? >> >> >> >> -- >> >> Rau >> >> >> >> On Mon, Feb 11, 2013 at 11:01 AM, Don Guinn <[email protected]> wrote: >> >> > Yes, I agree. not really pretty. Mostly I have wanted this when >> handling >> >> > errors. Another way would be to have 13!:13'' work when debug is not >> >> > active. All the information should be in the stack to produce the >> table. >> >> Or >> >> > does turning on debug cause additional information to be put in the >> >> stack? >> >> > >> >> > And another thing that would be nice would be to have another 13!:? >> >> signal >> >> > showing the error on the caller's line, like 13!:8 but not show the >> line >> >> in >> >> > error of the current definition. Make the output look like an error >> >> > encountered in a primitive. >> >> > >> >> > On Mon, Feb 11, 2013 at 8:24 AM, Raul Miller <[email protected]> >> >> wrote: >> >> > >> >> >> While this (x__1_) could be done, it would also violate some current >> >> >> locality guarantees -- code using it would become difficult to >> >> >> understand. >> >> >> >> >> >> A more robust approach would be to define a nested block mechanism >> for >> >> >> J, but even that needs a clear definition of why it's useful (but >> it's >> >> >> most useful where clarity is remote). >> >> >> >> >> >> -- >> >> >> Raul >> >> >> >> >> >> >> >> > ---------------------------------------------------------------------- >> >> > For information about J forums see >> http://www.jsoftware.com/forums.htm >> >> ---------------------------------------------------------------------- >> >> For information about J forums see http://www.jsoftware.com/forums.htm >> >> >> > ---------------------------------------------------------------------- >> > For information about J forums see http://www.jsoftware.com/forums.htm >> > >> ---------------------------------------------------------------------- >> For information about J forums see http://www.jsoftware.com/forums.htm >> > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
