Topic: Quit vs Exit in AutoLisp

[mailmaverick]

Whats the difference between Quit and Exit in AutoLisp ?

[Kerry]

Essentially none.

[CAB]

TIC - One is poor technique and the other is lazy programing.

[mailmaverick]

TIC - One is poor technique and the other is lazy programing.

Please explain.

[CAB]

These are relevant to your question:

http://forums.autodesk.com/t5/visual-lisp-autolisp-and-general/quit-vs-exit/td-p/836439
http://www.afralisp.net/autolisp/tutorials/cond-vs-if.php

PS
The TIC is Tongue In Cheek and a dated expression meaning an attempt at humor.
Although a poor one I must admit. 

[JohnK]

I'd never seen that COND vs IF article on afralisp before; nice link CAB.

I agree with the use of COND over IF; I've had a few arguments over the use of IF vs COND and keeping the namespace hygienic. ...Not to mention the use of a BOOLE in place of a simple COND or IF statement (that drives me batty when the tactic is misused).

If I remember right, I would use QUIT in dialog box situations and not so much in regular application situations (you need to properly set up your error handler environment to handle their use). I assembled "a better error handler", from a few people's efforts. (just search the "show your stuff" forum for my name and error) that should get you started if you wanted to.

[mailmaverick]

These are relevant to your question:

http://forums.autodesk.com/t5/visual-lisp-autolisp-and-general/quit-vs-exit/td-p/836439
http://www.afralisp.net/autolisp/tutorials/cond-vs-if.php

PS
The TIC is Tongue In Cheek and a dated expression meaning an attempt at humor.
Although a poor one I must admit. 

As per the links shared by you, there is no difference between quit and exit.

However, if AUTOLISP has made these two commands, there has to be a difference.

There cannot be two commands for exactly same thing.

It would be good to know the difference for academic purposes.

[JohnK]

Why does there have to be a difference?

http://theswamp.org/~john/avlisp/#exit
http://theswamp.org/~john/avlisp/#quit

Set up an error handler and test them each.

[Bhull1985]

These are relevant to your question:

http://forums.autodesk.com/t5/visual-lisp-autolisp-and-general/quit-vs-exit/td-p/836439
http://www.afralisp.net/autolisp/tutorials/cond-vs-if.php

PS
The TIC is Tongue In Cheek and a dated expression meaning an attempt at humor.
Although a poor one I must admit. 

As per the links shared by you, there is no difference between quit and exit.

However, if AUTOLISP has made these two commands, there has to be a difference.

There cannot be two commands for exactly same thing.

It would be good to know the difference for academic purposes.

Could it just be that Autodesk assumed when exiting (or quitting) an app that the majority of persons would be accustomed to using one of these two commands?
And rather than to have the "quit"ters receive an 'Unknown command "QUIT". Press F1 for help.'
or
the "exit"ers have the opposite...they just decided to implement both commands for fluidity?
That's what I would guess, especially reading that there are no documented differences at least shown in this thread.

[Lee Mac]

TIC - One is poor technique and the other is lazy programing.

I completely agree - there are very few cases in which such functions cannot be avoided, in my mind they are the equivalent of resorting to a goto statement to control code evaluation...

Perhaps one of the few situations in which the use of such functions is unavoidable is within a vl-catch-all-apply expression to essentially break evaluation of a vlax-for expression when a certain condition is met in order to avoid unnecessary iteration of an entire collection - but this is also a rare case.

As for the difference between the two, as far as I am aware, there is none. This may seem redundant, but then remember that AutoLISP is a high-level language and consequently there are many functions which are present merely for convenience - after all, any cond expression can be written using a sequence of nested if expressions, any loop could be written using while, 1+/1- are entirely superfluous, etc. etc.

[Kerry]

As per the links shared by you, there is no difference between quit and exit.

The links said it.
I said it.
John's excellent avlisp help file for theSwamp saya it
The AutoLisp Help files said it.

However, if AUTOLISP has made these two commands, there has to be a difference.

Why does there have to be a difference ?

There cannot be two commands for exactly same thing.

Why ?

It would be good to know the difference for academic purposes.

Academic pursuits are excellent but you need to check your premises. There is no difference and no amount of assumptions and second guessing will change that.

[CAB]

I haven't been around AutoLisp / lisp long enough but could it be a legacy issue.
New function name created & old name not removed.

[Jeff H]

They are spelled different.

From the Lisp Console

Code: [Select]

_$ exit
#<SUBR @0000000031fde8b8 QUIT>
_$ quit
#<SUBR @0000000031fde8b8 QUIT>
_$
So looks like they both evaluate to calling the same subroutine.

[JohnK]

TIC - One is poor technique and the other is lazy programing.

I completely agree - there are very few cases in which such functions cannot be avoided, in my mind they are the equivalent of resorting to a goto statement to control code evaluation...

...

I apologize I am typing this via my phone so I'm keeping this brief.
goto is all together different. Comparing apples to oranges.

I wouldn't say that the functions usage is all that bad either (the goto is a negative connotation); after all they did make vl-exit-with-message.

[rkmcswain]

http://forums.autodesk.com/t5/visual-lisp-autolisp-and-general/quit-vs-exit/td-p/836439
http://www.afralisp.net/autolisp/tutorials/cond-vs-if.php

Just chiming in to say thanks for these links. Good reads.

[David Bethel]

An interesting read form Compuserve days in 1997 :


I wonder if Owen holds the same thoughts today <g>

I still use (exit) and (quit) regularly.

• Verifying release versions.
• Verifying External reference or support file existance
• Etc

-David

[Lee Mac]

TIC - One is poor technique and the other is lazy programing.

I completely agree - there are very few cases in which such functions cannot be avoided, in my mind they are the equivalent of resorting to a goto statement to control code evaluation...
...

goto is all together different. Comparing apples to oranges.

IMO, (exit) / (quit) is no different to saying "goto *error* function".

I wouldn't say that the functions usage is all that bad either (the goto is a negative connotation); after all they did make vl-exit-with-message.

The negative connotation was intentional - in my opinion, continued use of these functions breeds lazy programming as CAB has noted earlier: rather than crafting an appropriate conditional expression to control the program evaluation such that the program exits cleanly for all foreseeable scenarios, many may settle for simply crashing the program at any point if something doesn't go as planned...

Lee

[owenwengerd]

I wonder if Owen holds the same thoughts today <g>

Hah! I'll have to reread the thread to refresh my memory, but I'm pretty sure I held the same opinions about (quit) back then that I do today. It basically depends on your perspective. If your goal is purely functional, then you probably don't care either way. If your goal is to produce beautiful code, then some people will find one way more "beautiful" and some the other. I want to integrate and transcend both beauty and function, and make code that is *good*, even approaching perfection of form. And that requires the use of (quit), IMO.

[owenwengerd]

Yep. This is pretty much how I would do it today. Note that the error is percolated right up the stack of error handlers into the previous handler, rather than presuming to know best and preventing the user from having any control.

Code: [Select]

(defun MyFun (/ ErrExit MyError OldErr Handle)
  (defun ErrExit (msg) (MyError msg) (exit))
  (defun MyError (msg)
    (if Handle (CloseHandle Handle))
    (if OldErr
      (progn
        (setq *error* OldErr OldErr nil)
        (if (listp *error*) (*error* msg) (princ msg))))
  )
  (setq OldErr *error* *error* MyError)
  (if (WrongPlatform)
    (ErrExit "Wrong Platform, You Idiot!"))
  (if (WrongOS)
    (ErrExit "Wrong OS, You Ignorant Dufus!"))
  (setq Handle (OpenConnection))
  (if (WrongDatabase)
    (ErrExit "Sheesh!  You Are A Real Dingleberry!"))
  (DoStuff)
  (CloseConnection Handle)
)


[David Bethel]

LOL

Idiot Dufus Dingleberry  That's me! 

[JohnK]

TIC - One is poor technique and the other is lazy programing.

I completely agree - there are very few cases in which such functions cannot be avoided, in my mind they are the equivalent of resorting to a goto statement to control code evaluation...
...

goto is all together different. Comparing apples to oranges.

IMO, (exit) / (quit) is no different to saying "goto *error* function".

I wouldn't say that the functions usage is all that bad either (the goto is a negative connotation); after all they did make vl-exit-with-message.

The negative connotation was intentional - in my opinion, continued use of these functions breeds lazy programming as CAB has noted earlier: rather than crafting an appropriate conditional expression to control the program evaluation such that the program exits cleanly for all foreseeable scenarios, many may settle for simply crashing the program at any point if something doesn't go as planned...

Lee

Sorry for the late reply; I just got back from holiday vacation.

That describes every function call. -e.g. "goto sqrt <number>".

The negative connotation goto received was because of it's use in the C language; it's overuse created what is called spaghetti code. Lisp(ers) has a bad habit of this as well (one of the main reasons I created LiFP). But I digress, using Quit/Exit will give more robust code. However--and admittedly--its use is often overlooked and missed. They are not "bad" functions at all, just underused.

[JohnK]

Nice error handler owenwengerd.

[Kerry]

< .. > But I digress, using Quit/Exit will give more robust code. However--and admittedly--its use is often overlooked and missed. They are not "bad" functions at all, just underused.

 
I agree, providing there is a well designed mechanism to trap the error/exit and restore the environment to a pristine condition.

[RAYAKMAL]

(defun c:QY  () (command "quit" "y")) 

And I use EXIT when using DCL

Code: [Select]


   (if (not (new_dialog "ddblkmgr_info_dlg" dh))
       (exit)
   )
   (set_tile "ddblkmgr_info_dlg_lbl" "DDBlock Manager v.1 1995")
   ... ... ..


[danallen]

and I bet you turn autosave off...

(defun c:QY  () (command "quit" "y")) 

[Lee Mac]

That describes every function call. -e.g. "goto sqrt <number>".

Not quite -

When a function (such as sqrt) is evaluated, program evaluation resumes at the expression following the call to the function (without error); conversely, when (exit) or (quit) are used, program evaluation is ceased by forcing an error, hence my comparison to a 'goto *error* function'...

But I digress, using Quit/Exit will give more robust code.

How? Could you elaborate?

[David Bethel]

But I digress, using Quit/Exit will give more robust code.

I agree.  To me, (exit / quit) is more like 'Go directly to jail, DO NOT pass Go, DO NOT collect $200'.   Less chances for screw ups

[Lee Mac]

But I digress, using Quit/Exit will give more robust code.

I agree.  To me, (exit / quit) is more like 'Go directly to jail, DO NOT pass Go, DO NOT collect $200'.   Less chances for screw ups

But how is forcing an error any more robust than writing a condition to cleanly complete evaluation of the defun expression?

[ronjonp]

But I digress, using Quit/Exit will give more robust code.

I agree.  To me, (exit / quit) is more like 'Go directly to jail, DO NOT pass Go, DO NOT collect $200'.   Less chances for screw ups

But how is forcing an error any more robust than writing a condition to cleanly complete evaluation of the defun expression?

I don't understand either Lee. 

[David Bethel]

While it is probably possible to test for evey possible scenario prior to
calling a set_mode or any other function, it is far more straight forward ( IMO )
to issue an (exit) / (quit) and have the error handler cancel out any active command
, end the undo group and then undo all changes to database, and then issue the
return_mode function in a single step.

Code - Auto/Visual Lisp: [Select]

1.  
2. ;++++++++++++ Set Modes & Error ++++++++++++++++++++++++++++++++++
3. (defun nw_smd ()
4.  (SetUndo)
5.  (setq olderr *error*
6.       *error* (lambda (msg)
7.                 (while (> (getvar "CMDACTIVE") 0)
8.                        (command))
9.                 (and (/= msg "quit / exit abort")
10.                      (princ (strcat "\nError: *** " msg " *** ")))
11.                 (and (= (logand (getvar "UNDOCTL") 8) 8)
12.                      (command "_.UNDO" "_END" "_.U"))
13.                 (nw_rmd)))
14.  
15.  (setvar "INSBASE" '(1 1 0))
16.  
17.  (princ))
18.  
19. ;++++++++++++ Return Modes & Error +++++++++++++++++++++++++++++++
20. (defun nw_rmd ()
21.   (setq *error* olderr)
22.   (command "_.UNDO" "_END")
23.   (prin1))
24.  
25. ;++++++++++++ Set And Start An Undo Group ++++++++++++++++++++++++
26. (defun SetUndo ()
27.  (and (zerop (getvar "UNDOCTL"))
28.       (command "_.UNDO" "_ALL"))
29.  (and (= (logand (getvar "UNDOCTL") 2) 2)
30.       (command "_.UNDO" "_CONTROL" "_ALL"))
31.  (and (= (logand (getvar "UNDOCTL") 8) 8)
32.       (command "_.UNDO" "_END"))
33.  (command "_.UNDO" "_GROUP"))
34.  
35. ;++++++++++++ Test Bed +++++++++++++++++++++++++++++++++++++++++++
36. (defun c:exitquit (/ olderr a)
37.  
38. (nw_smd)
39.  
40. (and (wcmatch (getvar "ACADVER") "*13*")
41.      (wcmatch (getvar "PLATFORM") "*Win*")
42.      (setq a "13WIN"))
43.  
44. (entmake (list (cons 0 "CIRCLE")(cons 40 1)(list 10 0 0 0)))
45.  
46. (if (/= a "13WIN")
47.     (progn
48.       (alert "This Program Only Work In Release 13 For Windows")
49.       (exit)))
50.  
51. (nw_rmd)
52. (prin1))
53.  
54.  

Without using the *error* handler, INSBASE remains '(1 1 0)
Also any geometry created prior to the abort remains.

This is a scenario I have due the fact my rendering program only runs in Release 13 Windows. 

But only if I choose a AccuRender2 as an option.  If it is a hidden line, shaded surface, wireframe image,
the autocad release doesn't matter.

If the value is an option based on user inputs nested deeply in the main program, thats a lot
code to have to clear out.

I'm sure there are arx programs that have similar limitations and simply exit when
trying to be loaded on incorrect platforms.

[JohnK]

I literally have one minute so I will type fast.

https://en.wikipedia.org/wiki/Tail_call#History

I really don't want to engage in a "Worse is Better" type of discussion so I will part with the last bit of wisdom I have regarding the topic. As a programmer you should not be codified (thinking there are always structured rules and regulations) when receiving/processing/outputting information outside the "walls" of your application. ...but you know that (it is up to you to decide).