Page 1 of 3 123 LastLast
Results 1 to 10 of 24

Thread: Error Handling in LISP/Net

  1. #1
    Certifiable AUGI Addict irneb's Avatar
    Join Date
    2015-11
    Location
    Jo'burg SA
    Posts
    4,512
    Login to Give a bone
    0

    Default 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).
    Knowledge is proportional to experience, but wisdom is inversely proportional to ego!
    My little bit of "wisdom": Hind-sight is useless, unless used to improve the next forethought!

  2. #2
    Past Vice President / AUGI Volunteer peter's Avatar
    Join Date
    2000-09
    Location
    Honolulu Hawaii
    Posts
    1,029
    Login to Give a bone
    0

    Default Re: Error Handling in LISP/Net

    Quote Originally Posted by irneb View Post
    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)
     )
    AutomateCAD

  3. #3
    Certifiable AUGI Addict irneb's Avatar
    Join Date
    2015-11
    Location
    Jo'burg SA
    Posts
    4,512
    Login to Give a bone
    0

    Default Re: Error Handling in LISP/Net

    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.
    Knowledge is proportional to experience, but wisdom is inversely proportional to ego!
    My little bit of "wisdom": Hind-sight is useless, unless used to improve the next forethought!

  4. #4
    Past Vice President / AUGI Volunteer peter's Avatar
    Join Date
    2000-09
    Location
    Honolulu Hawaii
    Posts
    1,029
    Login to Give a bone
    0

    Default Re: Error Handling in LISP/Net

    I started a new thread on Error Handling

    Lets move the conversation on this over there.


    P=
    AutomateCAD

  5. #5
    Past Vice President / AUGI Volunteer peter's Avatar
    Join Date
    2000-09
    Location
    Honolulu Hawaii
    Posts
    1,029
    Login to Give a bone
    0

    Default Re: 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)
     )
    )
    AutomateCAD

  6. #6
    Administrator BlackBox's Avatar
    Join Date
    2009-11
    Posts
    5,520
    Login to Give a bone
    0

    Default Re: Error Handling in LISP/Net

    Quote Originally Posted by peter View Post
    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
    "How we think determines what we do, and what we do determines what we get."

    Sincpac C3D ~ Autodesk Exchange Apps

    Computer Specs:
    Dell Precision 3620, Core i7-7700K 4.2GHz, 64GB RAM, Samsung 970 Pro M.2, 8GB NVIDIA Quadro P4000

  7. #7
    Certifiable AUGI Addict irneb's Avatar
    Join Date
    2015-11
    Location
    Jo'burg SA
    Posts
    4,512
    Login to Give a bone
    0

    Default 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
    Knowledge is proportional to experience, but wisdom is inversely proportional to ego!
    My little bit of "wisdom": Hind-sight is useless, unless used to improve the next forethought!

  8. #8
    Certifiable AUGI Addict irneb's Avatar
    Join Date
    2015-11
    Location
    Jo'burg SA
    Posts
    4,512
    Login to Give a bone
    0

    Default 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
    Knowledge is proportional to experience, but wisdom is inversely proportional to ego!
    My little bit of "wisdom": Hind-sight is useless, unless used to improve the next forethought!

  9. #9
    Past Vice President / AUGI Volunteer peter's Avatar
    Join Date
    2000-09
    Location
    Honolulu Hawaii
    Posts
    1,029
    Login to Give a bone
    0

    Default 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
    Last edited by peter; 2014-01-16 at 06:26 AM.
    AutomateCAD

  10. #10
    Certifiable AUGI Addict irneb's Avatar
    Join Date
    2015-11
    Location
    Jo'burg SA
    Posts
    4,512
    Login to Give a bone
    0

    Default 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.
    Knowledge is proportional to experience, but wisdom is inversely proportional to ego!
    My little bit of "wisdom": Hind-sight is useless, unless used to improve the next forethought!

Page 1 of 3 123 LastLast

Similar Threads

  1. Error Handling
    By ticad02 in forum AutoLISP
    Replies: 16
    Last Post: 2009-12-21, 03:39 PM
  2. Error Handling
    By whattaz13 in forum AutoLISP
    Replies: 2
    Last Post: 2008-07-16, 01:03 PM
  3. Error handling
    By dfuehrer in forum AutoLISP
    Replies: 8
    Last Post: 2007-09-24, 04:17 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •