Error handling in AutoLISP programmes 1
Print This Post
 |
Author | Erhan Toker |
| Profession | Architect M.Sc. | |
| Autodesk Authorized Consultant | ||
| Software Specialist | ||
All AutoLISP versions
When an error occurred in the AutoLISP functions, a meaningless message appears in the command line and the function stops to run. Although the LISP programming language is very flexible, it is insufficient considering this point. Thus, I am going to try explaining these errors by preparing a feuilleton (series of articles). Firstly, let us take a look at the error handling functions of AutoLISP (Figure 1).
Table.1
The topic of this first part of the series of articles is (*error* errtxt) function. As you all know, we use ‘!func-name’ expression in the command line to learn the address or definition of a function in AutoCAD. By means of this expression, let us try the original state of our function:
Komut Akışı
Before defining the function, let us look at what is going on when we encounter an error. Thus, I am writing a function to cause an error (Figure 2).
Figure 2
Running this function causes an error in AutoCAD.
Komut Akışı
This is a difficult situation for the programmer and the user. Besides, command breaks down in a bad way. Of course, there is nothing left to do for the cases that the user can not compensate, but at least the error message may be more explanatory. This makes the error report more understandable for the programmer. So, let us define our error function. (Figure 3)
Figure 3
The ‘Error’ word and the real error report are united and wrote down in a new line in the very first expression of the function. To unite the expressions, use (strcat s1 s2 ...) function. Place the original (*error*) function on the second expression of the function. Of course, g:olderr variable had to be matched with the original function before. This process had to done on the error sending function. Thus, let us arrange the (c:test) function in a way that the error can be explanatory (Figure 4).
Figure 4
Original error function is assigned to a global variable as the first thing in our newly added lines. Then, replace the original error function with the one we created. There is an important issue in the line we added lastly. If our error function is defined before the error is encountered, the original error function has to be put in its place. Now, let us take a look at how our error function proceeds:
Komut Akışı
As you can see, error message runs as we defined. Yet, the source function of the error is not clear. There is not an automatic solution for this. But, it can be solved by another global variable. Let us rearrange our error function (Figure 5):
Figure 5
As it can be seen, before the error message, the source function of the error is printed with the ‘g:errfnc’ variable that stores the name of the function. So, our first job when defining functions should be storing the function names (Figure 6):
Figure 6
The place of the line added newly is not important. Yet, it must be before the error occurs. It is better to define it at the beginning of the function. Let us now run the faulty function:
Komut Akışı
So, we have learned in detail how (*error*) function runs. Yet, there is a point not to be forgotten: After replacing the error function with the original one it becomes the default function until you go back to the original one. It will be enough to define only the ‘g:errfnc’ variable if you appload other functions than the ‘TEST’ function.
Similar Posts
Rate this article:
(No Ratings Yet)
Loading ...
Loading ...