Author Topic: Quit vs Exit in AutoLisp  (Read 11947 times)

0 Members and 1 Guest are viewing this topic.

David Bethel

  • Swamp Rat
  • Posts: 656
Re: Quit vs Exit in AutoLisp
« Reply #15 on: January 01, 2015, 07:13:41 AM »
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
« Last Edit: January 01, 2015, 07:16:47 AM by David Bethel »
R12 Dos - A2K

Lee Mac

  • Seagull
  • Posts: 12905
  • London, England
Re: Quit vs Exit in AutoLisp
« Reply #16 on: January 01, 2015, 09:13:06 AM »
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

  • Bull Frog
  • Posts: 451
Re: Quit vs Exit in AutoLisp
« Reply #17 on: January 01, 2015, 11:00:36 AM »
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

  • Bull Frog
  • Posts: 451
Re: Quit vs Exit in AutoLisp
« Reply #18 on: January 01, 2015, 11:29:41 AM »
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

  • Swamp Rat
  • Posts: 656
Re: Quit vs Exit in AutoLisp
« Reply #19 on: January 01, 2015, 03:20:25 PM »
LOL

Idiot Dufus Dingleberry  That's me! 
R12 Dos - A2K

JohnK

  • Administrator
  • Seagull
  • Posts: 10604
Re: Quit vs Exit in AutoLisp
« Reply #20 on: January 05, 2015, 01:55:32 PM »
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.
TheSwamp.org (serving the CAD community since 2003)
Member location map - Add yourself

Donate to TheSwamp.org

JohnK

  • Administrator
  • Seagull
  • Posts: 10604
Re: Quit vs Exit in AutoLisp
« Reply #21 on: January 05, 2015, 01:57:02 PM »
Nice error handler owenwengerd. :)
TheSwamp.org (serving the CAD community since 2003)
Member location map - Add yourself

Donate to TheSwamp.org

Kerry

  • Mesozoic relic
  • Seagull
  • Posts: 11654
  • class keyThumper<T>:ILazy<T>
Re: Quit vs Exit in AutoLisp
« Reply #22 on: January 05, 2015, 06:40:16 PM »
< .. > 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.

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

kdub, kdub_nz in other timelines.
Perfection is not optional.
Everything will work just as you expect it to, unless your expectations are incorrect.
Discipline: None at all.

RAYAKMAL

  • Guest
Re: Quit vs Exit in AutoLisp
« Reply #23 on: January 05, 2015, 07:02:56 PM »

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

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")
   ... ... ..
« Last Edit: January 05, 2015, 07:10:39 PM by RAYAKMAL »

danallen

  • Guest
Re: Quit vs Exit in AutoLisp
« Reply #24 on: January 05, 2015, 08:10:04 PM »
and I bet you turn autosave off...

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

Lee Mac

  • Seagull
  • Posts: 12905
  • London, England
Re: Quit vs Exit in AutoLisp
« Reply #25 on: January 06, 2015, 08:41:53 AM »
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?
« Last Edit: January 06, 2015, 08:52:34 AM by Lee Mac »

David Bethel

  • Swamp Rat
  • Posts: 656
Re: Quit vs Exit in AutoLisp
« Reply #26 on: January 06, 2015, 10:00:31 AM »
Quote
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
R12 Dos - A2K

Lee Mac

  • Seagull
  • Posts: 12905
  • London, England
Re: Quit vs Exit in AutoLisp
« Reply #27 on: January 06, 2015, 10:09:26 AM »
Quote
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

  • Needs a day job
  • Posts: 7526
Re: Quit vs Exit in AutoLisp
« Reply #28 on: January 06, 2015, 10:35:19 AM »
Quote
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. 

Windows 11 x64 - AutoCAD /C3D 2023

Custom Build PC

David Bethel

  • Swamp Rat
  • Posts: 656
Re: Quit vs Exit in AutoLisp
« Reply #29 on: January 06, 2015, 02:14:09 PM »
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.  
  53.  


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.
R12 Dos - A2K