Jump to content

Recommended Posts

Posted

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

Posted

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.

Posted

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?

Posted

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

Posted

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.

Posted

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

Posted
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.

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.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...