Error Handling in LISP/Net
One thing I'm still scratching my head around is a way to return a normal Lisp-like error through a DotNet exception class. I.e. I'd like to be able to use vl-catch-all-apply to check for errors as with most already built-in lisp functions, and keep the command-line as clean as possible (i.e. silent exit of error to use alternative code).
Re: Wishlist - Got an idea for a new function for LISP?
Quote:
Originally Posted by
irneb
One thing I'm still scratching my head around is a way to return a normal Lisp-like error through a DotNet exception class. I.e. I'd like to be able to use vl-catch-all-apply to check for errors as with most already built-in lisp functions, and keep the command-line as clean as possible (i.e. silent exit of error to use alternative code).
Good one!
One thing I have been trying to adopt throughout all of my code (.NET or LISP) is to trap errors at the level of each function.
In LISP that means returning a value or a T_atom for success and nil for failure.
I like to wrap my code with and (and ...) and that way it drops out immediately upon hitting an error.
I do that in .NET with checking the return value from each function similarly.
I have a function for LISP that I use called Errortrap that wraps each function call with an error trapping function that returns a value or T for success and nil for failure
(errortrap (quote (setq x (/ 1 0))) ; returns nil because you can't divide by zero.
Code:
(defun ErrorTrap (symFunction / objError result)
(if (vl-catch-all-error-p
(setq objError (vl-catch-all-apply
'(lambda (X)(set X (eval symFunction)))
(list 'result))))
nil
(if result result 'T)
)
Re: Wishlist - Got an idea for a new function for LISP?
Yes, I know the return value/T and nil on error idea. But then what about an error message. E.g. say the exception was due to user cancelling on input. Usually in lisp you'd silently blank such error messages by making a custom *error* defun and checking the message for its contents. But with DotNet's exception it seems it's an all-or-nothing idea: Either you throw the exception and let it trace the entire DotNet stack to the command-line, or you catch the exception and return nil to Lisp (difficult to allow lisp to search the "message").
1st prize would be if a custom LispException class can be made which when not caught would return a vl-error to whatever lisp evaluation called it. Also throwing Lisp into its *error* function with the message passed as argument (unless the call was wrapped within a vl-catch-all-apply). There has to be a way, since it is obviously implemented inside ARX from other built-in functions (thus the divide by zero type error) - the / function is probably inside the vl.arx file (or built into acad.exe) - anyone know if there's some callable function which could do this (perhas through PInvoke)?
2nd prize would be to return some specialized object value (similar to the vl-error code) within which the error message is contained and can be extracted. But this might cause hassles, since then you leave it up to the lisp code to check if such object is returned instead of nil or and error stopping the code.
Joint 2nd prize: use the return nil idea and (at least) set some global variable to the error message. Doesn't actually throw an error, so the *error* defun (if used for something else) would become redundant in this case. Would need to document this global var so Lisp-side users of the DLL would need to know where to check.
In the last 2 methods consistency is lost. I.e. DotNet's LispFunctions work different when erroring than any other functions. Could confuse Lispers as they now have a 3rd way in which they have to check for errors. This is my reason for not liking the return-nil idea as much as a full-fledged lisp-error.
Re: Wishlist - Got an idea for a new function for LISP?
I started a new thread on Error Handling
Lets move the conversation on this over there.
P=
Error Handling in LISP/Net
This stores the last error in a global variable that could be checked and reset.
I tend not to use *Error* very much but occasionally
I use the value/T and nil methodology to handle the errors in the flow.
P=
I find that .net is very unstable when handling errors, whereas LISP is almost bulletproof.
I would rather handle errors in LISP... IMHO probably just because I am more used to it.
Lets start a new thread on Error Handling.... OK?
P
Code:
(defun ErrorTrap (symFunction / objError result)
(if (vl-catch-all-error-p
(setq objError (vl-catch-all-apply
'(lambda (X)(set X (eval symFunction)))
(list 'result))))
(progn
(setq strGlobalErrorMessage (strcat
(vl-catch-all-error-message objError)
(princ "\nWhile evaluating the expression: ")
(vl-princ-to-string symfunction)
)
)
nil
)
(if result result 'T)
)
)
Re: Wishlist - Got an idea for a new function for LISP?
Quote:
Originally Posted by
peter
I started a new thread on Error Handling
Lets move the conversation on this over there.
Just passing through on my short lunch break....
I've moved the other related posts here, so someone just finding this thread doesn't start in the middle of a neat topic.
A quick $0.02 - I would love for other native Objects to be exposed as valid return Types for LispFunctions (i.e., COM Objects, vl-Error, etc.), however, ADN staff tell me this is not possible.
Cheers
Re: Error Handling in LISP/Net
Just as an aside, error handling in VB.DotNet is a bit inconsistent. The legacy On Error Goto (from old VB6/VBA) is still allowed due to backward compatibility. The trouble of course is when you convert the VB code to other DotNet languages - no other language uses the Goto statements. They've been omitted from nearly all "new" languages since they tend to cause complicated and messy control flow - making the code difficult to understand. MSDN recommends using the try-catch approach instead, since you can achieve the same thing you wanted to do with On Error Goto, only in a more structured and understandable manner. The only thing I know of which On Error can do and try-catch can't is On Error Resume Next - but is that really something you think is correct code (it would be something like a try-ignore statement)?
Some further dicussion on this: http://forums.devx.com/showthread.ph...Try-Catch-Fail
Re: Error Handling in LISP/Net
Another idea could be to create a temporary volatile ename to use as a return value on errors. Now, to figure out how to accomplish this in DotNet instead of ARX as per Owen's suggestion here: http://www.theswamp.org/index.php?to...9841#msg469841
Re: Error Handling in LISP/Net
OK...
I use the On Error Goto OnError method because it is cleaner than try/catch.
It is 3 lines of code compared to 5.
Because I only want the function to return a value/True or nothing/nil and I test for success in the calling function.
Whatever the error is... I want my program to continue and I can deal with the error later.
Being I have programmed basic since 1974 and used Goto statements a long time, I like it.
If you see it and think a try catch is cleaner, you are more than welcome to switch it and repost or convert to other languages.
I switched from try/catch to this more simple syntax as I was refining some of my code a while back.
There are no good writes, just rewrites.
P=
I will try to include the try catch syntax to make it easier to translate.
Let me show you what I see.
Code:
Public Function TestFunction(ByVal rbfLISPArguments As ResultBuffer)
' 5 lines of code to handle errors
Try
' the code
Return tpvTrue
Catch ex As System.Exception
End Try
Return tpvNil
End Function
Code:
' 3 lines of code to handle errors
Public Function TestFunction(ByVal rbfLISPArguments As ResultBuffer)
On Error GoTo OnError
' the code
Return tpvTrue
OnError: Return tpvNil
End Function
What I would like to see is
On Error Return Nothing ... or something like that
Re: Error Handling in LISP/Net
Sorry, not trying to say it's wrong. I also "started" with Basic in DOS - while still in school. And I did remember that (as long as you keep your wits bout you ;)) the goto's actually gave you a lot of funky capabilities. It's just that these days they're considered bad practise. BTW, the try-catch-finally is implemented (after compilation) as assembly branches - i.e. the exact same thing as a goto statement. The thinking is that it's just a more structured source-code, thus less chance of something going wrong inadvertently.