Topic: Abort and return to command prompt

[David Hall]

the above could be combined using the LISP version of AND, once I learn how

[irneb]

Somewhat contrived use of (exit):

Code: [Select]

(defun _Document_Has_XRefs ( document / result )

    (vl-catch-all-apply
        (function
            (lambda ( )
                (vlax-for block (vla-get-blocks document)
                    (if (eq :vlax-true (vla-get-isxref block))
                        (progn
                            (setq result T)
                            (exit)
                        )
                    )
                )
            )       
        )       
    )

    result

)
Cheers.

I think this would always return nil. Seeing as the first block in the blocks collection would be the model space - which isn't an xref. And thus the exit is called on the first block. Though you do mention it's a contrived usage 

Edit:

*allowing time for post edit before posting correction*

Sorry ... yes I missed the progn when reading this.  :-[ Stupid of me. Sorry MP! It's novel I must say!

[David Hall]

do you have a non-vlisp example?  I haven't learned all the Vlisp commands

[Lee Mac]

I think this would always return nil. Seeing as the first block in the blocks collection would be the model space - which isn't an xref. And thus the exit is called on the first block.

*allowing time for post edit before posting correction*

[David Hall]

This was what I used as an example
http://www.theswamp.org/index.php?topic=50.msg366#msg366

[irneb]

do you have a non-vlisp example?  I haven't learned all the Vlisp commands

Here's  simplistic idea to show something which happens quite often:

Code - Auto/Visual Lisp: [Select]

1. (defun c:DrawOneLine  (/ pt1 pt2 osmode cmdecho *error*)
2.   (defun *error*  (msg)
3.     (and osmode (setvar "OSMODE" osmode))
4.     (and cmdecho (setvar "CMDECHO" cmdecho))
5.     (cond ((not msg))
6.           ((wcmatch (strcase msg) "*EXIT*,*ABORT*,*QUIT*"))
7.           (t (princ msg)))
8.     (princ))
9.   (if (and (setq pt1 (getpoint "Pick line's start point: "))
10.            (setq pt2 (getpoint pt1 "Pick line's end point: ")))
11.     (progn (setq osmode  (getvar "OSMODE")
12.                  cmdecho (getvar "CMDECHO"))
13.            (setvar "OSMODE" 0)
14.            (setvar "CMDECHO" 0)
15.            (command "_.LINE" pt1 pt2 "")))
16.   (*error* nil))

There are better way to write the above. But it serves much like RenderMan's situation - i.e. use the *error* routine to clean up even if there was no error.

Say the above is started transparently during another command. The line command would fail with a "Function canceled" error message. The *error* defun would still ensure that osmode & cmdecho are reset back to what they were.

Also if the user presses ESC (or you add an exit, perhaps due to a point not inside a defined area) that message won't be displayed on the command-line. If you want it displayed then omit that wcmatch line, or modify for other messages.

[Eddie D.]

Not related to your topic, CMDRDUH, but it's good to see someone else on The Swamp that does substation design!

[Kerry]

the above could be combined using the LISP version of AND, once I learn how

Perhaps something like this David

Code - Auto/Visual Lisp: [Select]

1.  
2. (if (and
3.         (= (strcase bshgt) "LOW")
4.         (< *LOWBUS* 98)
5.     )
6.     (progn
7.         (alert "Too Low!")
8.         (exit)
9.     )
10. )
11.  
12.  

Just yell if you need help

Stay well,
Kerry

[David Hall]

Thats the ticket Kerry! thanks.  I knew it would be easy.  I am still thinking in .Net and cant remember the old LISP ways.

[Lee Mac]

Here is how I might code it:

Code - Auto/Visual Lisp: [Select]

1. (cond
2.     (   (and (= (strcase bshgt) "LOW") (< *LOWBUS* 98))
3.         (alert "Too Low!")
4.     )
5.     (   t
6.         <Rest of Program>
7.     )
8. )

This avoids the need to use exit to force an error since the program will cease evaluation of the cond expression when a test expression returns a non-nil value. Of course, in this particular case where there is only a single condition to be tested, an if expression could also be used in place of the cond expression, however, usually there is more than one error condition to be checked, and so cond becomes more suitable (and readable) than multiple nested if statements.

In fact, I use this construct in almost all of my programs which utilise DCL, as, in my opinion, it is cleaner than using exit, doesn't necessarily require an *error* handler, and furthermore retains the flow of the code (i.e. the program is being evaluated line by line rather than aborting).

My 2p 

[owenwengerd]

Here is how I might code it:

Code - Auto/Visual Lisp: [Select]

1. (cond
2.     (   (and (= (strcase bshgt) "LOW") (< *LOWBUS* 98))
3.         (alert "Too Low!")
4.     )
5.     (   t
6.         <Rest of Program>
7.     )
8. )

I think this makes code more readable:

Code - Text: [Select]

1. (if (and (= (strcase bshgt) "LOW") (< *LOWBUS* 98))
2.   (progn (alert "Too Low!") (exit)))
3.  
4. (if (failed-p (test1))
5.   (exit))
6.  
7. (if (failed-p (test2))
8.   (exit))
9.  

I want the error condition to cause an immediate failure without getting propagated and without being hidden intside a fancy structure (or indented 20 spaces), and I want it to be obvious when scanning the code 30 years later what the control flow is here.

[Lee Mac]

I shan't argue with your evident programming expertise Owen and I respect your opinion, but I can't say that this structure:

Code - Auto/Visual Lisp: [Select]

1. (if (failed-p (test1))
2.     (progn
3.         (princ "\nTest1 failed.")
4.         (exit)
5.     )
6. )
7.  
8. (if (failed-p (test2))
9.     (progn
10.         (princ "\nTest2 failed.")
11.         (exit)
12.     )
13. )
14.  
15. (if (failed-p (test2))
16.     (progn
17.         (princ "\nTest1 failed.")
18.         (exit)
19.     )
20. )

is any more readable than:

Code - Auto/Visual Lisp: [Select]

1. (cond
2.     (   (failed-p (test1))
3.         (princ "\nTest1 failed.")
4.     )
5.     (   (failed-p (test2))
6.         (princ "\nTest2 failed.")
7.     )
8.     (   (failed-p (test3))
9.         (princ "\nTest3 failed.")
10.     )
11. )

I don't think the level of indentation plays any part since both would have to be indented to the level at which the conditions are to be tested in any case.

[Kerry]

< .. >
I want the error condition to cause an immediate failure without getting propagated and without being hidden intside a fancy structure (or indented 20 spaces), and I want it to be obvious when scanning the code 30 years later what the control flow is here.

I concur !

I shan't argue with your evident programming expertise Owen and I respect your opinion, but I can't say that this structure:

Code - Auto/Visual Lisp: [Select]

1. (if (failed-p (test1))
2.     (progn
3.         (princ "\nTest1 failed.")
4.         (exit)
5.     )
6. )
7.  
8. (if (failed-p (test2))
9.     (progn
10.         (princ "\nTest2 failed.")
11.         (exit)
12.     )
13. )
14.  
15. (if (failed-p (test2))
16.     (progn
17.         (princ "\nTest1 failed.")
18.         (exit)
19.     )
20. )

is any more readable than:

Code - Auto/Visual Lisp: [Select]

1. (cond
2.     (   (failed-p (test1))
3.         (princ "\nTest1 failed.")
4.     )
5.     (   (failed-p (test2))
6.         (princ "\nTest2 failed.")
7.     )
8.     (   (failed-p (test3))
9.         (princ "\nTest3 failed.")
10.     )
11. )

I don't think the level of indentation plays any part since both would have to be indented to the level at which the conditions are to be tested in any case.

Lee, You're assuming the assertion tests can all be collected together.
I've never had a situation where that can be achieved that I recall.
... Particularly when dealing with code that is any considerable length.

Regards
Kerry

[Kerry]

Just for an option.
This is really old .. and it is called innumerable times each day.

Code - Auto/Visual Lisp: [Select]

1.  
2. ;;;------------------------------------------------------------------
3. ;;;------------------------------------------------------------------
4. ;;;
5. ;;; Spit the Dummy if 'testStatement evaluates to nil
6. ;;; argument must be quoted
7. ;;;   (setq var 0)
8. ;;;   (KDUB:assert 'var "Symbol 'VAR' has no value assigned.")
9. ;;;   (KDUB:assert '(not(zerop var)) "Symbol 'VAR' evaluates to 0 ... this is illegal ... go to jail")
10. ;;;   (KDUB:assert '(> var 0) nil)
11. ;;;   (KDUB:assert '(< var 1) nil)
12. (defun kdub:assert (teststatement message)
13.   (if (not (eval teststatement))
14.     (progn (kdub:display-message
15.              " **** Assertion Failure"
16.              (if message
17.                message
18.                (list (vl-prin1-to-string teststatement) " ==>> nil/null")
19.              )
20.            )
21.            ;; decide what to do here later ?
22.            (if kglobal:debug_on
23.              (princ "  ")
24.              (exit)
25.            )
26.     )
27.   )
28.   (princ)
29. )
30. ;;;------------------------------------------------------------------
31. ;;;------------------------------------------------------------------
32.  
33.  

[Kerry]

This goes with that

Code - Auto/Visual Lisp: [Select]

1.  
2. ;;;------------------------------------------------------------------
3. ;;;
4. ;;; (KDUB:display_formatted_message prefix mess )
5. ;;; kwb 20020715
6. ;|
7. prefix : String or nil
8. mess   : atom or list comprising STRing, INT, REAL,
9.          SYMbol, ENAME, VLA-OBJECT, FILEid etc
10. |;
11. ;;;
12. ;;; Print a formatted message to the command line
13. ;;;
14.  
15. (defun kdub:display-message (prefix mess)
16.   (mapcar 'princ
17.           (list "\n"
18.                 (if (= (type prefix) 'str)
19.                   prefix
20.                   "; **** ERROR"
21.                 )
22.                 ": "
23.           )
24.   )
25.   (if (vl-consp mess)
26.     (mapcar 'princ mess)
27.     (princ mess)
28.   )
29.   (princ)
30. )
31.  
32. ;;;------------------------------------------------------------------
33. ;;;------------------------------------------------------------------
34.  

.. thanks John boy