Conditional Error Trapping
Error Trapping is one of those topics that are immune from criticism,
but let's assume that our aim when developing an application is to
ensure that the ultimate end user is never confronted with an APL error
Each implementation of APL offers its own approach to error trapping -
it's one of those things that has never really been standardised.
Indeed, even within a single vendor's product we can
sometimes find more than one way to deal with errors.
In this page there's no real attempt to consider the merits of the
different implementations, it just looks at one mechanism that has been
present in Dyalog APL for a few years.
However, let's drive two stakes into the ground...
Error-trapping should never be used to implement application logic,
it's there to handle the truly unexpected.
There needs to be a way to expose the real errors during the
development and maintenance processes.
Here's an example of how the second objective can be achieved in Dyalog
∇ z←a foo
 ⍝ Demonstrate optional
 :Trap #.TrapsOn/0
TrapsOn←1 ⍝ For the
2 foo 0
TrapsOn←0 ⍝ For the
2 foo 0
- In reality <foo> would be arbitrarily complex
this example we are setting a trap for "everything", in reality we
would probably only trap specific error conditions at deeper levels
within the code hierarchy
- Relying on a global variable to control whether errors are exposed is probably one of the valid uses of globals
- :Trap is in a sense a disguise for the arguably more versatile ⎕TRAP, and it is prudent (if strictly unnecessary) to localise to insulate against unexpected coding techniques.
Page last updated 26
Copyright © Dogon