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
