:Trap 0

[kai]

I just found this in the Link code:

Code: Select all

 
:Trap 0 ⋄ names←(2 FIX src)  ⍝ fn/op/script - can work from file
 :Else ⋄ names←0⍴⊂''
 :EndTrap

This is not only bad because it uses ⋄ when it shouldn't, it's particularly bad because it uses :Trap 0 without safety net.

Any error (that might surprise you very much) is hidden. In case something goes wrong here, the only way to find out is to trace until you get to this very line.

:Trap 0 is only acceptable in very rare circumstances, and then in the :Else proper action needs to be taken in order to find out what was going wrong, and what's the best way to inform the user. Just returning something empty is not enough.

Also, any :Trap 0 should honour a switch as in

Code: Select all

:Trap DEBUG↓0

This can at least be switched off.

If one day we are going to agree on a style guide for how to write APL code, then this should be mentioned pretty early in the "Don't, ever" section.

[Morten|Dyalog]

I'm on holiday and don't have time to read the code, so perhaps I should not comment until I am back at work. But I think that in this particular case there *is* a safety net. Link is trying to fix all the files in a folder, some of them don't contain APL source code and will thus be ignored. I suspect it will warn the user (at least it should) if the expected list of names produced is not as expected.

There may be bugs in the code, but I suspect this could be one of the cases where a :Trap 0 is actually an acceptable solution. It may be a bit lazy, but it is very hard to be sure that it is wrong without checking the context to be sure that the behaviour is not as desired.

Explicit validation is of course always better, but in this case I think it would be very difficult to code.

Back to sailing, don't expect me to read responses for another week :-).

[Adam|Dyalog]

I'll let Morten answer in time, but here are a couple of personal comments:

As I mention in my personal style guide, I'm not keen on this sort of diamond usage, and in general I prefer to do tests rather than rely on error trapping.

Your advice about :Trap DEBUG↓0 is very timely. I am presenting an error handling webinar on Thursday, and will make sure to include this trick. Thanks!

[kai]

1.

There are 21 hits for :Trap 0 in Link alone.
(Interestingly there are also 18 hits for :Trap DEBUG↓0 )

2.

I am not complaining because I think that checks are better than trapping errors, though usually they are better.

I am also not complaining that the user is not warned in this particular case although she should be.

What is far worse is that the zero traps all errors, including VALUE, RANK and NONCE errors among many others that just cannot reasonably occur in this particular context.

Over the decades I have seen many cases when in a situation were the programmer expected just file errors but was too lazy to specify them and therefore went for all of them (0), and then a bug popped up in the shape of, say, a NONCE error caused by a bug in the interpreter, yet it was ignored, causing havoc elsewhere.

Therefore, trap errors you expect, not all of them.

There are still scenarios when it makes sense to really catch all errors, but in very few cases, and then the trap should indeed handle them somehow.

[Morten|Dyalog]

Back from holiday, catching up on e-mail but have not had time to read all the code. However, although I agree with your general comments about not misusing :Trap 0, I believe there may be some justification in this case. Link is looping through the files in a folder and trying to ⎕FIX them into the active workspace. A failure of a file to ⎕FIX is NOT necessarily considered an error in Link, so it would be inappropriate for a general DEBUG flag to cause Link to stop on such failures. In other words, I think you would need to add an additional STOPONFIXFAILURE flag for this to work the way you really want it to and not just drive it off DEBUG.

Obviously, validation is better, but writing APL code to validate whether a source file contains valid APL source code is not really realistic, so doing a :Trap 0 and seeing what happens is the best we can do right now. The real problem is that ⎕FIX needs to become a bit more of an API, which is something that we're planning to look at in the next release cycle, so that Link can have a bit more of a firm foundation to stand on.

I believe the user WILL usually get an error message if the fixing does not produce the expected results. Do you have an example of a case where things are failing silently that I could chase down?

[paulmansour]

Code: Select all

Trap 0 ⋄ names←(2 FIX src)  ⍝ fn/op/script - can work from file
 :Else ⋄ names←0⍴⊂''
 :EndTrap

Is this missing a quad? Is that ⎕FIX or a user-defined function FIX?

[kai]

Morten:

I don't have a real case right now, no.

Paul:

It's a function which is established locally in either line 7 or line 11.