Topic: *error* trapping

[kdub_nz]

I've mentioned this previously, but I'm still seeing a mistake in function design that will destroy the users current settings.

This relates to the design of Lisp error handling routines.

the current design typically in samples

Code - Auto/Visual Lisp: [Select]

1. (defun c:xdtb_function (/      local_vars )
2.   (defun *error* (msg)
3.     (princ msg)
4.     (xdrx_entity_delete m_pl_ent mirr_ent e_axis t)
5.     (xdrx_entity_redraw e-axis 4)
6.     (redraw)
7.     (setq *error* nil)
8.     (xdrx_end)
9.   )
10.  
11.   ;|
12.       code continues
13.  
14.   |;
15.  
16.   (xdrx_sysvar_pop)
17.   (setq *error* nil)
18.   (xdrx_end)
19.   (princ)
20. )
21.  

(defun *error* (msg) ...  defines a GLOBAL *error* handling function that overwrites any current settings the user has.
then  (setq *error* nil) assignes nill to the definition.

This is bad practice.

At the least, the *error* function should be local to it's parent, ie

Code - Auto/Visual Lisp: [Select]

1. (defun c:xdtb_function (/  *error*    local_vars ) ;; <- declare *error* local
2.   (defun *error* (msg)
3.     (princ msg)
4.     (xdrx_entity_delete m_pl_ent mirr_ent e_axis t)
5.     (xdrx_entity_redraw e-axis 4)
6.     (redraw)
7.     ;;(setq *error* nil) <- not needed
8.     (xdrx_end)
9.   )
10.  
11.   ;|
12.       code continues
13.  
14.   |;
15.   (xdrx_sysvar_pop)
16.   (xdrx_end)
17.   (princ)
18. )
19.  

Another option is to call the *error*  function at the end of the parent to do the clean-up work.

Code - Auto/Visual Lisp: [Select]

1. (defun c:xdtb_function (/  *error*    local_vars ) ;; <- declare *error* local
2.   (defun *error* (msg)
3.     (princ msg)
4.     (xdrx_entity_delete m_pl_ent mirr_ent e_axis t)
5.     (xdrx_entity_redraw e-axis 4)
6.     (redraw)
7.     ;;(setq *error* nil) <- not needed
8.     (xdrx_sysvar_pop)  <- added
9.     (xdrx_end)
10.   )
11.  
12.   ;|
13.       code continues
14.  
15.   |;
16.  
17.   ;; (xdrx_end) <- removed
18.   (*error* nil)   ;; <- call *error* with nil for cleanup
19.   (princ)
20. )
21.  

Another option is to make a default error handler that you can call

Code - Auto/Visual Lisp: [Select]

1. (defun default:on-error (msg / )
2.   ;;----- Cancel any Active Commands -------------------------------------
3.   (while (< 0 (getvar 'cmdactive)) (command-s nil))
4.   (setvar 'menuecho 1)
5.   ;;----- Display error message if applicable _---------------------------
6.   (cond ((not msg))
7.         ((member (strcase msg t)
8.                  '("console break"
9.                    "function cancelled"
10.                    "quit / exit abort"
11.                   )
12.          )
13.          (princ "\nFunction Cancelled.")
14.         )
15.         ((princ (strcat "\nApplication Error: "
16.                         (itoa (getvar 'errno))
17.                         " :- "
18.                         msg
19.                 )
20.          )
21.          ;;----- Display backtrace ------------------------------------------
22.          (vl-bt)
23.         )
24.   )
25.   (setvar 'errno 0)
26.   (vla-endundomark *:activedoc) ;; <- any defauly cleanup.
27.   (princ)
28. )
29.  

Then use it something like this

Code - Auto/Visual Lisp: [Select]

1. (defun c:xdtb_function (/  *error*    local_vars ) ;; <- declare *error* local
2.   (defun *error* (msg)
3.     ( default:on-error msg )
4.    
5.     (xdrx_entity_delete m_pl_ent mirr_ent e_axis t)
6.     (xdrx_entity_redraw e-axis 4)
7.     (redraw)  
8.     (xdrx_sysvar_pop)  <- added
9.     (xdrx_end)
10.   )
11.  
12.   ;|
13.       code continues
14.  
15.   |;
16.  
17.  
18.   (*error* nil)
19.   (princ)
20. )
21.  
22.  

I know from experience this will keep your users happier, and save a lot of nasty emails.
As a bonus, if there is an error, the causes will be more obvious.

Regards,

[It's Alive!]

Is this per document? What happens if you call (xdrx_sysvar_pop) in another document?

[kdub_nz]

R.T.F.M. perhaps

oh, wait . . .


All I did was move the call from the code body to the error handler.
Do you see  a problem with that ?

and yes, it's in the document namespace.

[It's Alive!]

I was just wondering the state, example if (xdrx_sysvar_pop) or (xdrx_end) is called in one document, does it affect the state of xdrx in other documents.
ads_func() isn’t going to be document aware, special handling would be required in xdrx for maintaining a per document state.

just curious

[kdub_nz]

I honestly don't know the internal workings on the arx Dan.
I did ask for details on the functionality of (xdrx-begin), (xdrx_sysvar_pop), (xdrx_end) but  none has been forthcoming,  except a link to a Chinese site which can't translate properly ( in my experience ) and told to search for it.

[xdcad]

R.T.F.M. perhaps

oh, wait . . .


All I did was move the call from the code body to the error handler.
Do you see  a problem with that ?

and yes, it's in the document namespace.

Define XD::BEGIN，XD::END like this

Code - Auto/Visual Lisp: [Select]

1. (defun XD::Begin ()
2.   (defun default:on-error (msg /)
3.     ;;----- Cancel any Active Commands -------------------------------------
4.     (while (< 0 (getvar 'cmdactive)) (command-s nil))
5.     (setvar 'menuecho 1)
6.     ;;----- Display error message if applicable _---------------------------
7.     (cond ((not msg))
8.           ((member (strcase msg t)
9.                    '("console break" "function cancelled" "quit / exit abort")
10.            )
11.            (princ "\nFunction Cancelled.")
12.           )
13.           ((princ (strcat "\nApplication Error: "
14.                           (itoa (getvar 'errno))
15.                           " :- "
16.                           msg
17.                   )
18.            )
19.            ;;----- Display backtrace ------------------------------------------
20.            (if (= (xdrx-getvar "debug") 1)
21.              (vl-bt)
22.            )
23.           )
24.     )
25.     (setvar 'errno 0)
26.     (princ)
27.   )
28.   (defun *error* (msg)
29.     (default:on-error msg) ;General error function handling
30.     (apply 'xdrx_document_setprec *XD:PREC*)
31.     (eval (list #xd-error-callback-func)) ;User-defined error function handling
32.     (redraw)
33.     (xdrx_sysvar_pop)
34.     (xdrx_end)
35.   )
36.   (setq *XD:PREC*    (xdrx_document_getprec))
37.   (xdrx-begin)
38. )

Code - Auto/Visual Lisp: [Select]

1. (defun XD::End()
2.   (*error* nil)
3.   (princ)
4. )
5.  

Code - Auto/Visual Lisp: [Select]

1. (defun XD::Error:SetCallBack (str)
2.   (cond
3.     ((and
4.        (= (type str) 'str)
5.        (= (type (eval (read str))) 'SUBR)
6.      )
7.        (setq #xd-error-callback-func (read str))
8.     )
9.     ((= (type str) 'SUBR)
10.        (setq #xd-error-callback-func str)
11.     )
12.   )
13. )
14.  

===============

Code - Auto/Visual Lisp: [Select]

1. (defun c:test()
2.   (defun myerr()
3.     (princ "\n User-defined error function handling")
4.     (princ)
5.   )
6.   (xd::begin)
7.   (xd::error:setcallback "myerr")
8.   .......
9.   (xd::end)
10.   (princ)
11. )
12.  

[kdub_nz]

WHAT !!

Are you now telling us that you have been using code that I wrote yesterday in your library ?

I don't understand.

//--------

I have been asking for details on the functionality of (xdrx-begin), (xdrx_sysvar_pop), (xdrx_end) etc to ensure the integrity of the environment for users code.

I also asked for the definition YOU use for XD::BEGIN，XD::END etc for the same reason.

I also suggested a more professional handling of errors in the samples provided.

//----------

Please understand that I am not attacking you, the library functionality displayed is impressive !

I am just attempting to determine the safety and side-effects of some of the functionality you have hidden in compiled code.

You may be comfortable using the ARX, VLX, FAS files because you know  and understand what is behind them.

It's a different story for us who are writing software for our own firms or for clients. Our livings and reputations depend on the performance and safety on the thousands of lines of code we write.

It would be embarrassing and rediculous to tell a client that we don't know what is causing a specific side-effect to the code we wrote for him.

Regards,

[xdcad]

WHAT !!

Are you now telling us that you have been using code that I wrote yesterday in your library ?

I don't understand.

//--------

I have been asking for details on the functionality of (xdrx-begin), (xdrx_sysvar_pop), (xdrx_end) etc to ensure the integrity of the environment for users code.

I also asked for the definition YOU use for XD::BEGIN，XD::END etc for the same reason.

I also suggested a more professional handling of errors in the samples provided.

//----------

Please understand that I am not attacking you, the library functionality displayed is impressive !

I am just attempting to determine the safety and side-effects of some of the functionality you have hidden in compiled code.

You may be comfortable using the ARX, VLX, FAS files because you know  and understand what is behind them.

It's a different story for us who are writing software for our own firms or for clients. Our livings and reputations depend on the performance and safety on the thousands of lines of code we write.

It would be embarrassing and rediculous to tell a client that we don't know what is causing a specific side-effect to the code we wrote for him.

Regards,

I saw your code yesterday, and based on your ideas, I wrote it yesterday
No need to be too sensitive,

In the process of using the API, if you have any questions, you can post them directly and concisely.

Since English is not my native language I need to understand it correctly and then....

[kdub_nz]

In the process of using the API, if you have any questions, you can post them directly and concisely.

Since English is not my native language I need to understand it correctly and then....

OK, directly and concisely :

I have been asking for details on the functionality of (xdrx-begin), (xdrx_sysvar_pop), (xdrx_end) etc to ensure the integrity of the environment for users code.

I also asked for the definition YOU use for XD::BEGIN，XD::END etc for the same reason.

[xdcad]

1. xdrx-sysvar-pop

Used in conjunction with xdrx-sysvar-push, xdrx-sysvar-pop restores the state of the system variables set by the last call to xdrx-sysvar-push, which can be nested

Code - Auto/Visual Lisp: [Select]

1. (xdrx-sysvar-push '(("osmode" 2)("cmdecho" 0) .....))
2.        .........
3.        (xdrx-sysvar-push '(("blipmode" 1).....))
4.        .........
5.        (xdrx-sysvar-pop)
6.        .........
7. (xdrx-sysvar-pop)

If the T parameter is given, (xdrx-sysvar-pop t), it will directly restore to the earliest one (xdrx-sysvar-push....)

=========

These two functions are only related to system variables and have no additional operations.

=========

One principle of the XDRx API is to help LISP users reduce code as much as possible, making the code clearer and more direct.

The above two functions reduce the need for LISP users to protect the site before setting system variables and then restore the site.

[kdub_nz]

I just looked closely at your  (defun XD::Begin ()

You seem to be missing my point about making the *error* function local to the main routine.

From your previous posts ,  XD::Begin and XD::End are compiled into a VLX/FAS file.

You have the *error* function declared inside the XD::Begin function with global scope.

This means that whenever XD::Begin is called the *error* function is re-defined globally ; this will destroy any *error* functionality the user has defined, and it can't be restored.
If we are using your API to produce code for our clients we are likely to have unpleasant side-effects.

This methodology also means that the developer can not add specific functionality to the *error* handling for his main function.

//------------

I read your comments about xdrx-sysvar-push.

I understand what it's intent is because I have used the methodology myself for years. There are probably several posts on this forum regarding the matter.

Again, my main issue is transparency and possible side-effects.
Most of these issues should be covered in the help file you are producing/translating.
I surpose the API users will just have to trust you.

Regards,

[xdcad]

2. xdrx-begin, xdrx-end
Use in pairs , Nested use is not recommended

Under normal circumstances, xdrx-begin mainly sets several system variables, cmdecho, osmode, coords, calyer, and can be automatically restored through paired xdrx-end.
In addition, undoend, undostart are set

xdrx-end, restore the system variables set by xdrx-begin, then, undoend, xdrx-sysvar-pop

The rest, there are some API internal variable settings and restores, users don’t need to worry about it.

=====

Although xdrx-sysvar-pop is called in xdrx-end, from the perspective of clear code logic, it is recommended to use xdrx-sysvar-push and xdrx-sysvar-pop in pairs.

[xdcad]

I just looked closely at your  (defun XD::Begin ()

You seem to be missing my point about making the *error* function local to the main routine.

From your previous posts ,  XD::Begin and XD::End are compiled into a VLX/FAS file.

You have the *error* function declared inside the XD::Begin function with global scope.

This means that whenever XD::Begin is called the *error* function is re-defined globally ; this will destroy any *error* functionality the user has defined, and it can't be restored.
If we are using your API to produce code for our clients we are likely to have unpleasant side-effects.

This methodology also means that the developer can not add specific functionality to the *error* handling for his main function.

//------------

I read your comments about xdrx-sysvar-push.

I understand what it's intent is because I have used the methodology myself for years. There are probably several posts on this forum regarding the matter.

Again, my main issue is transparency and possible side-effects.
Most of these issues should be covered in the help file you are producing/translating.
I surpose the API users will just have to trust you.

Regards,

you may not have noticed

Code - Auto/Visual Lisp: [Select]

1. (defun *error* (msg)
2.     (default:on-error msg) ;General error function handling
3.     (apply 'xdrx_document_setprec *XD:PREC*)
4.     (eval (list #xd-error-callback-func)) ;User-defined error function handling
5.     (redraw)
6.     (xdrx_sysvar_pop)
7.     (xdrx_end)
8.   )

 (eval (list #xd-error-callback-func)) ;User-defined error function handling


Just use the callback function to perform what the user wants to do.
Use:
 (xd::error:setcallback "myerr")

to call back the user's own error execution code to the global *error* for additional execution, so that the user does not have to consider the general error handling part.

[kdub_nz]

Sorry, there is too much mis-direction and lack of transparency for me.

How is anyone meant to know and make efficient use of statements like that.

I won't bother you anymore.

[xdcad]

Sorry, there is too much mis-direction and lack of transparency for me.

How is anyone meant to know and make efficient use of statements like that.

I won't bother you anymore.

From your reply, I still haven’t figured out what you want.
Just from my understanding, I gave you the solution, and even used your common error code in the solution.

The code is open, anyone can customize it according to their own needs