Topic: Share your ERROR subroutine to get best one

[JohnK]

(setq olderr *error* *error* ErrorTrap)

[Lee Mac]

> I tend not to use command statements in my code.

why? There is nothing wrong with COMMAND if you are prepared for it. Besides, two commands like that means <ESCAPE> <ESCAPE>

I find most command calls unreliable and of course there is the performance aspect to consider - so I only use them if I have no other alternative or unless the alternative is 100's of lines of code...

> ...the second 'princ' would not be evaluated as the previous expression returns True...

See what i mean about confusing? `aesthetics' be damed. [you] or someone needs to maintain this. Make it easier on yourself; ditch the fancy obscure tricks and focus on the elegance.

I don't think two lines within an OR is confusing - its practically an  (if (not <xxx>) (then <xxx>) ...), it was you that suggested including the second princ in the statement - at which point it may become a little obscure...

Why even check the string if your not going to print it if it passes the check BTW? I'm actually kinda confused.

Again, the OR acts like an (if (not <xxx>) (then <xxx>) ...) - I am checking the string so that I don't print the 'Function Cancelled' etc messages.

[JohnK]

TOOL - Ænima is a very good album to debug code to.

[Kerry]

Lee,
John has an ongoing fixation about OR and COND .... you may ignore him if you like.   

[Kerry]

just a thought :

Don't we all stand on  the shoulders of giants ( a little ).

[HasanCAD]

just a thought :

Don't we all stand on  the shoulders of giants ( a little ).

YES we are.

[CHulse]

just a thought :

Don't we all stand on  the shoulders of giants ( a little ).

... or a lot! I know I'd be lost without the help of all of you here and at Cadtutor. I can atribute almost everything I know about cad to these forums ("self" taught)...
So Thanks.

[Lee Mac]

just a thought :

Don't we all stand on  the shoulders of giants ( a little ).

I suppose you hit the nail on the head - I too learn most of what I know from others examples 

[TimSpangler]

TOOL - Ænima is a very good album to debug code to.

Thats a good album to do anything to.  It was the best live show I had ever seen.

[alanjt]

It was the best live show I had ever seen.

Agree. Both times.

[JohnK]

Lee,
John has an ongoing fixation about OR and COND .... you may ignore him if you like.   

Its not a `fixation'. *Under breath: I'll fix you.*

That is only because OR returns a Boolean value not...no, wait (let me just say it)...it is *not* the same as "(if (not (<blah>...".

IMHO if you want to use OR that way then you should just switch to Scheme otherwise do what the rest of us do; use IF and or COND.  However, i am not totally against the use of OR in some situations. I think OR can be a very elegant method but *I* know how to use it and i feel that most times the user just thinks its a fancy trick. Hence, my comment about debugging code. Ive hunted down these "boolean errors" and seen what happens when you dont "know your returns" can do to the flow of an app and i say good luck.

[MeasureUp]

When these in different positions in the codes

Code: [Select]

[color=red]   (setq theERR *error*)
   (setq *error* ErrorHandling)[/color]
would the following codes make any difference?
Thanks for your helps.

Code: [Select]

(defun Test (/ *error* theERR)
   (defun ErrorHandling (msg)
    ...
   ); end of ErrorHandling
   ...
   MainFunctions Here
   ...
   [color=red](setq theERR *error*)
   (setq *error* ErrorHandling)[/color]
); end of Test


Code: [Select]

(defun Test (/ *error* theERR)
   (defun ErrorHandling (msg)
    ...
   ); end of ErrorHandling
   [color=red](setq theERR *error*)
   (setq *error* ErrorHandling)[/color]
   ...
   MainFunctions Here
   ...
); end of Test


[Kerry]

It's actually simpler than that.

You don't need the variable theERR  or the local-function  ErrorHandling

The *error* function is LOCAL to the routune ... so you don't need to be concerned with any global function named the same  (the acad default one) that may exist.


I'd do it like this :

Code: [Select]

(defun Test (/ *error* )
   (defun *error* (msg)
    ...
   ); end of ErrorHandling
   ...
   MainFunctions Here
   ...

  (princ)
); end of Test

for fun, have a look at the code I posted .. you'll see a statement that MAY cause a divide by zero error.
See if you can write a self contained routine that will trap that (or  in fact any) error.

Post the code when you're done.


[added]
BUT, if you wanted to use the methodology you posted, the second sample is correct.
The *error* function alias needs to be declared before it can be used ... so declare it after the handler definition
  

[MeasureUp]

Thanks.
What if the ErrorHandling function is outside of the Test code?

Sample 3

Code: [Select]

(defun ErrorHandling (msg)
    ...
); end of ErrorHandling

(defun Test (/ *error* theERR)
      ...
   MainFunctions Here
   ...
   [color=red](setq theERR *error*)
   (setq *error* ErrorHandling)[/color]
(princ)
); end of Sample 3

Sample 4

Code: [Select]

(defun ErrorHandling (msg)
    ...
); end of ErrorHandling

(defun Test (/ *error* theERR)
   [color=red](setq theERR *error*)
   (setq *error* ErrorHandling)[/color]
      ...
   MainFunctions Here
   ...
(princ)
); end of Sample 4


[Kerry]

Thanks.
What if the ErrorHandling function is outside of the Test code?

<.. >

In that case, simply do it like the following sample.

Just to clarify :
The AutoLisp engine looks for a function called *error* to handle breaks in evaluation.
If there is a Global function named *error* it will be used if no LOCAL *error* function is declared

Code: [Select]



(defun Test4a (/ *error* )
   (defun *error* (msg)
     ;; call the external handler
     (ErrorHandling msg)
     ;; do local handling
    ...
   )
   ;; ----- end of ErrorHandling -----

      ...
   MainFunctions Here
   ...
(princ)
); end of Sample 4a