TIC - One is poor technique and the other is lazy programing.
These are relevant to your question:
http://forums.autodesk.com/t5/visual-lisp-autolisp-and-general/quit-vs-exit/td-p/836439 (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 (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.
These are relevant to your question:
http://forums.autodesk.com/t5/visual-lisp-autolisp-and-general/quit-vs-exit/td-p/836439 (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 (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. :-D
TIC - One is poor technique and the other is lazy programing.
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. :-D
_$ exit
#<SUBR @0000000031fde8b8 QUIT>
_$ quit
#<SUBR @0000000031fde8b8 QUIT>
_$
So looks like they both evaluate to calling the same subroutine.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...
...
http://forums.autodesk.com/t5/visual-lisp-autolisp-and-general/quit-vs-exit/td-p/836439 (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 (http://www.afralisp.net/autolisp/tutorials/cond-vs-if.php)
goto is all together different. Comparing apples to oranges.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 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.
I wonder if Owen holds the same thoughts today <g>
(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)
)
Sorry for the late reply; I just got back from holiday vacation.goto is all together different. Comparing apples to oranges.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...
...
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
< .. > 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.
(if (not (new_dialog "ddblkmgr_info_dlg" dh))
(exit)
)
(set_tile "ddblkmgr_info_dlg_lbl" "DDBlock Manager v.1 1995")
... ... ..
(defun c:QY () (command "quit" "y")) :-D
That describes every function call. -e.g. "goto sqrt <number>".
But I digress, using Quit/Exit will give more robust code.
But I digress, using Quit/Exit will give more robust code.
QuoteBut 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
QuoteBut 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?