Lee Mac Posted January 10, 2009 Posted January 10, 2009 Ok, So I have seen a lot of different discussion on here about error handlers. I have spoken to the likes of ASMI, David Bethel, CAB to name a few... Some say to use an error handler like: (defun *error* (msg) .... ) And localise the *error* in the main function, Others have used the *error* function to reset systems variables: (*error* "") ; reset variables And some have disagreed and said to format the handler: (setq *error* (lambda (e) (cond.... ) Which is the correct way?! Cheers Lee Quote
ASMI Posted January 10, 2009 Posted January 10, 2009 It depends on the goal. My philosophy on this issue is simple: "restore as it was". But this is only because I have no idea where my work program. If a particular user needs to follow the philosophy may be different: "restore in accordance with the standard". I do not believe that has the right to disable an unknown guy BLIPMODE, he may like it. That is why I write local functions *error*, which relate only to my programs. I have never written standard terms of handling errors and did not have the stamps, each handler error is different. Quote
Lee Mac Posted January 10, 2009 Author Posted January 10, 2009 Good Point ASMI, instead of resetting to a standard set of variables, set to previous settings. But with the method of defining the handler as a local function, do you have to localise the *error* in the main function? Quote
David Bethel Posted January 10, 2009 Posted January 10, 2009 Lee, I don't think that there is a right answer as to how an *error* is defined ( setq vs defun ) I do believe that in an error condition, it should: Cancel a command if active Display a meaningful message when appropriate Undo all changes to the database that the program has made Call a reset mode subroutine The reset subroutine should: Reset the sysvar and modes to their original state End an Undo group Restore the *error* handler Attached is a discussion from 1997 the Compuserve days. This would have been about the time R13 was released and a lot of us where still using R12. I makes for some interesting reading, even though some of it gets a bit long winded. -David CLEAN.ZIP Quote
Lee Mac Posted January 10, 2009 Author Posted January 10, 2009 Thanks for your input David - I see this is a matter of much discussion - expecially according to the length of your attachment! The only reason I posted this thread is so that I could do things properly. I don't want to be answering people's problems and posting badly/incorrectly written routines. And so I wanted to learn from the more experienced on here and gain knowledge of how to format routines such as error handlers correctly. After reading your replies, I realise that there doesn't seem to be one standard method of assigning an error handler, and that everyone seems to make their own. I have looked at David's error template - noting that it includes all aspects of function resetting - including "undo groups" and a whole list of sysvars. In my error routines, I would normally define the errror as a sub function and collect those values of sysvars that I intend to change as the routine progresses. - eventually settting things to how they were at the end. I'd like to keep things short and simple, but would like to do things correctly. Quote
David Bethel Posted January 11, 2009 Posted January 11, 2009 Lee, This is one of the shortcomings of posting snippets of code vs full programs for forums like this. It hard to catch all of the possibilities in a short format. It is user's onus to make sure that have plenty of backups, know that the even with the best intent, programmers can make mistakes that could ruin their day. So its kind of 'Buyer Beware' and don't use this stuff on production drawings until proven worthy. -David Quote
Lee Mac Posted January 11, 2009 Author Posted January 11, 2009 Lee, This is one of the shortcomings of posting snippets of code vs full programs for forums like this. It hard to catch all of the possibilities in a short format. It is user's onus to make sure that have plenty of backups, know that the even with the best intent, programmers can make mistakes that could ruin their day. So its kind of 'Buyer Beware' and don't use this stuff on production drawings until proven worthy. -David Good point David, well said. After all, no-one on here is trying to provide malicious programs, but we can't account for every outcome. Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.