Author Topic: Abort and return to command prompt  (Read 5909 times)

0 Members and 1 Guest are viewing this topic.

owenwengerd

  • Bull Frog
  • Posts: 451
Re: Abort and return to command prompt
« Reply #30 on: August 09, 2012, 11:10:19 PM »
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.

In these contrived examples I can't disagree, but in a real application, IMO the indentation does become a factor because you inevitably have to nest multiple levels deep.

In your example, it's easier for someone to append code in the future after the (cond) without realizing that the appended code executes even during failure conditions. That's what I meant about "hiding" assertions inside a structure. There is no wrong way or right way, necessarily, but I think there is an unwarranted stigma to using (exit), and I hope you don't dismiss it out of hand. Part of my motivation is to dispel any myth that (exit) is a kludge that "real" programmers avoid.

BlackBox

  • King Gator
  • Posts: 3770
Re: Abort and return to command prompt
« Reply #31 on: August 10, 2012, 02:20:19 AM »
I do not feel that there is any stigma for or against using Exit; rather it's more likely that most simply use the best tool for the job at hand (which ends up not being Exit).

Most Visual LISP routines incorporate a change in sysvar, or external object which warrants a better option than Exit. In my limited experience, it is rare that I code a routine where Exit would be sufficiently effective.
"How we think determines what we do, and what we do determines what we get."

irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: Abort and return to command prompt
« Reply #32 on: August 10, 2012, 02:56:40 AM »
Usually ... when a function becomes so large that a cond structure becomes "lost" and/or obscured ... causing you to need exit: This means your function is too convoluted, at least for Lisp-best-practise. I've seen some, and I've written some myself (most notably my AutoIncr's main input function - from line 1657 here  :-[ - "when" I get the time I'm definitely going to re-write that, at the very least, into separate functions).

In the above AutoIncr sample I'd have to follow a method like MP's example in order to use the exit function - since I don't want the calling function to exit, only the current one. Which IMO might even make than function more convoluted, therefore the cond used is the best for that case. Though the contents of each cond makes the function lumber-some (never mind cumbersome). So in the "lisp-way" (though many languages advocate keeping each function minimal for ease of future support) would be to effectively extract each condition body into a separate defun of its own - then the condition would simply call that defun instead of inlining its code. That would make the cond structure a lot more readable for future edits.
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.