NLSETQ consiered Harmful

[masinter]

NLSETQ is an Interlisp function which is used to "hide" errors of any sort. (NLSETQ (dosomething))
is defined to evaluate (dosomething) and, if there's an error,return NIL; if there's an error of any sort at all, it returns (LIST dosomethingvalue). Usage is simple if you're executing and want to insure here is no error: call (CAR (NLSETQ (dosomething))).

This is, in Common Lisp terms, a CATCH of all errors. It doesn't distinguish error types at all. Medley has the Common Lisp condition system now integrated. It would be better to catch errors that are actually anticipated. NLSETQ will catch a control-E keystroke, or a storage full error, or errors that are really from some other cause.

I don't propose systematically trying to redefine all the calls to NLSETQ, but it's worth the trouble to try to avoid adding NEW calls to NLSETQ.

(More about NLSETQGAG and the use of NLSETQ to hide errors in HCFILES or adding initially when importing something which has too many errors to track down them all, but eventually get rid of it.

[rmkaplan]

I think that would be a good policy going forward. But for legacy issues it would require figuring out exactly where and why an error is being generated in code that we don't understand and are not really interestinged in devling into. If we don't really care why it fails and we just want it to go away, an NLSETQ is better than nothing.

[masinter]

I'm not sure of the tradeoffs here. The cost of fixing one bug when the "fix" introduces another reduces the stability of the code. We wind up with even more messes that are undebugable. We have no automated tests or regression tests or other ways of testing integrity. I'd rather we try to avoid situations that patch around errors quietly without understanding why they occurred.

Running with NLSETQGAG set to NIL would at least show you where unexpected errors occurred.

[nbriggs]

I think SEDIT:GET-SELECTION was rewritten without thinking about whether there was always a selection. This is how it used to read (years and years ago):

(DEFUN GET-SELECTION (CONTEXT)
   (LET ((SELECTION (IL:FETCH SELECTION IL:OF CONTEXT)))
        (COND
           ((OR (NOT (IL:FETCH SELECT-NODE IL:OF SELECTION))
                (NOT (EQ (IL:FETCH SELECT-TYPE IL:OF SELECTION)
                         'STRUCTURE)))
            (VALUES NIL NIL))
           ((IL:FETCH SELECT-START IL:OF SELECTION)
            (VALUES (STRUCTURE-FROM-SELECTION SELECTION)
                   :SUB-LIST))
           (T (VALUES (STRUCTURE-FROM-SELECTION SELECTION)
                     T)))))

Someone introduced at LET* with a binding such that it attempts to
(CHARS (IL:FETCH STRUCTURE IL:OF NODE))
before it gets to

         (COND
            ((NULL NODE)
             (VALUES NIL NIL))

So I definitely would NOT just wrap an NLSETQ around the caller -- it was supposed to return NIL, but someone broke it.

[tfeb]

On 16 Jun 2026, at 02:02, Larry Masinter ***@***.***> wrote: This is, in Common Lisp terms, a CATCH of all errors. It doesn't distinguish error types at all. Medley has the Common Lisp condition system now integrated. It would be better to catch errors that are actually anticipated. NLSETQ will catch a control-E keystroke, or a storage full error, or errors that are really from some other cause.

One thing you could do (given the CL condition system) would be to temporarily replace code that uses NLSETQ by a macro which behaves the same, except it establishesa handler for ERROR conditions (or the appropriate type) which loggs them somewhere but then simply returns NIL the way NLSETQ does. You'd want to use HANDLER-BIND so you can know where the thing happens better. That would provide some visibility into what nasties NLSETQ is hiding from you.

…

--tim

[masinter]

NLSETQGAG to NIL will accomplish this I believe.

[nbriggs]

Meanwhile -- let's take OUT the NLSETQ in the CLIPBOARD code around the call to SEDIT:GET-SELECTION, and fix the bogus code that was introduced into SEDIT:GET-SELECTION that attempts to fetch fields from an object that may be NIL. SEDIT:GET-SELECTION is not supposed to error, it's supposed to return (VALUES NIL NIL) if there is no node selected in the context.

[masinter]

General issue #2668 opened ...
closing this discussion