Error Trapping

For users of dfns, both novice and expert

Error Trapping

Postby paulmansour on Mon Jun 08, 2015 4:01 pm

So every 5 years or so, I have to do some error trapping. It is always deja vu all over again. I am surprised when the error guard 0:: does not catch errors farther down the stack. I then remember the scoping rules.

Anyway, here is the question: what are the various techniques for global error trapping of a dfn? I can think of two useful solutions.

1. Make sure all the sub dfns are defined within the top level dfn, then 0:: will catch everything.

2. Write a traditional operator to call the dfn, something like:

      z←x(f Try)y
⍝ Try function f on y.
:Trap 0
z←f y
:Else
Signal an error here with message x, or return something, etc.
:EndTrap



Any other techniques worth noting?
paulmansour
 
Posts: 341
Joined: Fri Oct 03, 2008 4:14 pm

Re: Error Trapping

Postby JohnS|Dyalog on Tue Jun 09, 2015 9:51 am

Hi Paul,
The only other technique that springs to mind is to catch and ⎕signal at each capsule (outermost dfn) level.

    {
        0::⎕signal ⎕en        ⍝ pass un-trapped error back to caller.
        ...

I appreciate this adds a fair amount of clutter, particularly for small capsules.

We are strongly considering changing error guards to have dynamic, rather than lexical scope, so that the following would work:

    main←{0::'Eh?' ⋄ sub ⍵}
    sub←{÷⍵}
    main 0
Eh?

How would people feel about this? Would this change break anyone's code?
John.
JohnS|Dyalog
 

Re: Error Trapping

Postby Phil Last on Tue Jun 09, 2015 10:48 am

Acre's technique is merely a slight enhancement of John's whereby the zero is replaced by a call to function Error (say) and the - ⎕SIGNAL ⎕EN is replaced by function Signal (say) so each "capsule" is headed by:
      [1] Error''::Signal''

Error may be defined such that it returns either zilde or zero depending on whether a globally accessible debug setting is set on or off:
      Error←{settings.debug↓0}

Signal may be derived as:
      Signal←⎕SIGNAL/∘{⌽⎕EN,⎕DM}

Using the first item of ⎕DM wherever it is called allows it to pass on a bespoke error message.
User avatar
Phil Last
 
Posts: 549
Joined: Thu Jun 18, 2009 6:29 pm

Re: Error Trapping

Postby Phil Last on Tue Jun 09, 2015 10:55 am

JohnS wrote:How would people feel about this? Would this change break anyone's code?

Would this change break anyone's code? wouldn't be surprised either way because after eighteen years of lexical I find dynamic scope quite counter-intuitive and the interaction between the two almost inexplicable.

How would people feel about this? a backward step?
User avatar
Phil Last
 
Posts: 549
Joined: Thu Jun 18, 2009 6:29 pm

Re: Error Trapping

Postby JohnS|Dyalog on Tue Jun 09, 2015 11:52 am

I should have been more specific. The proposal is to maintain lexical scope for error guards within a capsule, which is a requirement of tail-call optimisation, but to allow the guard to leak across only capsule-to-capsule calls. Where a "capsule" is the outermost dfn, which may contain any number of inner nested dfns.

The proposed behaviour should affect only an error that is currently un-trapped. We feel that error-trapping is special and unlike other scope scenarios and (some of us quite strongly) that the current behaviour is broken.

Rest assured, we wouldn't make this change without a strong consensus that it's the right way to go.
Rest assured also that this is not the slippery slope for lexical scoping, which IMHO is a wonderful thing.
John
JohnS|Dyalog
 

Re: Error Trapping

Postby paulmansour on Tue Jun 09, 2015 1:26 pm

John,

Thanks for the response. I think the change is a good idea, but I would not be comfortable with the change unless Phil and most if not all the top dfnistas were sold on it. It would certainly remove the need for the periodic head scratching that I engage in.

Can I take it that you are using more than the royal "we" here:

We feel that error-trapping is special and unlike other scope scenarios and (some of us quite strongly) that the current behaviour is broken.


and that you are not acting under pressure from scheming court advisers? ;)

I assume you are for this change?

Paul
paulmansour
 
Posts: 341
Joined: Fri Oct 03, 2008 4:14 pm

Re: Error Trapping

Postby JohnS|Dyalog on Tue Jun 09, 2015 7:21 pm

:-) There's no arm-twisting.

I think this is a good idea, so long as the change is restricted to error-guards on capsule-to-capsule calls. I suppose this could break existing code by inserting a new error-guard between the called function and a global catch-all.

If we're worried about this, perhaps we should investigate a new, distinct dynamic error-guard mechanism. How about three colons?

    {0:::'Eh?' ⋄ foo ⍵}    ⍝ Dynamic error guard active within called fn foo.
JohnS|Dyalog
 

Re: Error Trapping

Postby Phil Last on Tue Jun 09, 2015 10:03 pm

Maybe it's the global catch-all or the similarity to it that dynamic scope presents that worries me. Sometimes you just want your code to stop at the error without having to worry whether some unknown process is going to intervene that just happens to be somewhere further up the stack.

When each subsystem has its own protocol you really don't want one interfering with another.

I guess so long as it's totally predictable exactly how ALL the different mechanisms: ⎕TRAP, :Trap, :: interact and what has priority at different levels when each has its own selection of error codes it should be OK.
User avatar
Phil Last
 
Posts: 549
Joined: Thu Jun 18, 2009 6:29 pm

Re: Error Trapping

Postby kai on Wed Jun 10, 2015 7:27 am

Having battled with error trapping on what I call "a general level" a lot I can only express my strong support for a change here.

I am particularly happy with the three-colon-solution. It's easily distinguishable from ordinary error guards and it would not break anything I guess. Excellent.
User avatar
kai
 
Posts: 115
Joined: Thu Jun 18, 2009 5:10 pm
Location: Stevenage, UK

Re: Error Trapping

Postby paulmansour on Mon Apr 11, 2016 11:39 am

Further thoughts on error guards and dynamic scope.

One of the pitfalls of ⎕Trap is that trapping all errors can lead to an infinite loop with an error in the error handling code.

The keyword :Trap avoids this.

If dfn error guards were changed to be dynamically scoped, then they would behave like :Trap, is that correct? That is, this:

      {
0::HandleAnyError 0
RunMainProgram 0
}



would be essentially the same as this:

      :Trap 0
RunMainProgram 0
:Else
HandleAnyError 0
:EndTrap


I think I would vote to have the behavior of error guards changed.
paulmansour
 
Posts: 341
Joined: Fri Oct 03, 2008 4:14 pm

Next

Return to Functional Programming

Who is online

Users browsing this forum: No registered users and 1 guest