Handling Exceptions

[peter]

This thread was started discussing removal of xdata but focused on the handling of exceptions, so I moved it to its own thread.

[BlackBox]

I am sure that many things are possible using old fashioned autolisp... that is not my point...

Peter, my friend -

Words have meaning... These statements, and those made above, are mutually exclusive.

We both share an appreciation for, and interest in extending, LISP. So let's do exactly that by putting out the most accurate information, and quality examples we can.

I know you're very passionate about this topic, and I want for this initiative to be successful as well... Please do not take my comments & corrections personally, as they're intended to help the reader.

The focus of this forum is to extend the power of LISP creating useful functions in .NET...

Equally important is not letting new developers incorrectly believe that they don't need to account for exception handling in their LispFunction Methods, as I once (stubbornly) believed, and Gile was kind enough to educate me (I owe him a few bottles of Champagne for all that he's taught me )... Properly validating both the number, and type of parameters supplies with a given LispFunction Method's ResultBuffer is essential.

An excerpt from one of my many, many learning moments in .NET development (in this instance, specifically LispFunction Method) best practices:

...

An exception will be thrown if there's more or less than one argument or if a non-number is passed to 2x.
One reason this is not mandatory in .NET is that you can define a single LISP functions with a variable number and type of arguments (which cannot be done in LISP) and this requires a robust arguments checking.

...

Returning nil (null in .NET) rather than throwing an exception may be "preference" in some cases, but IMO only if nil (null) is a valid return value type, on no account for a number (this won't be possible in .NET where numbers aren't nullable).

...

When we implement LISP functions (or classes, frameworks, ...) to be used by other programmers, we have to make them as robust and safe, and also as comfortable to use as possible.
IMO it's no so comfotable to have to systematically check if the return value of a function is nil.

Separately, have you considered implementing a 'using' statement in your Transaction call? Why opt for a Document Transaction, when the entity data is Database resident?

Cheers

[peter]

It is my opinion that most errors can be handled by the programmer.

In the style I prefer, I choose to make sure the arguments are the correct type.

Rather than throw an exception for a number instead of a string, I just use the tostring and convert whatever it is to a string.

I also use case statements that ignore extra arguments...
and have been working on a general solution for converting typedvalue result buffers to arguments and back.

I also like to allow the user to have different numbers of arguments, including 0 if possible.

I also manage the errors by checking success at the end of a function by returning nothing or nil for failure and a value, true, or a T_Atom at the end for success.

I handle the exception in the routine rather than have a lot of error statements mess up the command prompt.

I recognize that you prefer to have exception feedback and I think that is a valid way of doing it too.

I do think for demonstrating basic functionality, adding exception handling is more complicated than handling the errors in the flow.

So for simple examples I prefer to not include them.

In your posts I have no problem with you demonstrating them and including them in your examples... It is just another way of doing it.

[peter]

If you look at my lisp code I like to use the 'and' statement to handle errors

(if (and
     (function1 "test")
     (setq xyz (function2 "test"))
     (errortrap (quote (/ 1 0)))
     etc...
    )
 (princ "\nSuccess!!!")
 (princ "\nOops something didn't work - handle the error")
)

This style which I prefer... it immediately drops out if an error is detected, but it doesn't crash the program.

I hope you understand the reasoning behind the 'nil' return value now.

I just continue on in my loop or whatever.

I am always contemplating what it means if I encounter an error and what it will do to the results of the routine.

p=

[peter]

I would like to explore ideas that would move the handling of exceptions out of base functions into an encapsulated function that could be called from the base function in a single function call.

Exceptions do provide useful information to the programmer, but putting all of the exception functionality in all of your base functions is redundant and IMHO clouds the simplicity of a base function.

I have thought of using xml to transfer all of the information to the error exception handler.

Like if I pass the arguments, required data types, and default values to the exception handler, it should be able to check all of them and create the error messages if required and return the data values back to the base function without messing up the code.

That way a single function could handle all of the argument exceptions.

I would be interested in looking at anyone elses code that has tried to do that.

p=

[BlackBox]

It seems that the original, incorrect statements made on the inability to remove XData with vanilla LISP (which prompted me to participate in the first place) have not been included here, when moving these posts to a new thread... Please restore those as well for clarity / context.

[peter]

I left the comments on the xdata post in the thread with the xdata and split the thread on exceptions to here.

They seemed to be two different subjects and this subject justified its own thread.

p=

[BlackBox]

Just to be complete, I recoded the above example to use the entmod method mentioned by blackbox for you LISP purists.

I had been monitoring Keans site and he was discussing removal of xdata and so I thought I would expose that functionality
to lisp using .net. That is why I tried to code it using .net. I haven't really studied removal of xdata using lisp or .net until today.

I was just playing around solving a programming puzzle and I solved it using .net and with blackbox's suggestion created the pure lisp version too.

I wanted to have a function that would remove xdata from a selection set of objects with a wildcard application name filter.

I like CAB's solution too... Its all good.

This post must have come in while I was typing....

I appreciate the motivation, and strongly encourage you to continue exploring how to extend LISP. You're very talented, and creative. As a wiser man than I once said, 'I prefer clarity to agreement'. I'd like to believe that we have more in common than not.

Cheers

[irneb]

I was thinking of something similar. I.e. a class working in the opposite direction as the ObjectToTypedValue class in the other thread. This should convert the result buffer into its object(s) - perhaps some list/array.

While it's at it, it should also check to see if the correct types are found in the resbuf as was expected. Unfortunately this last aspect is very complex to achieve (especially for a general purpose class). There may be infinite combination possibilities, e.g. some argument might be allowed to be more than one type (e.g. int and real). Another argument might be allowed to be omitted. You'd need some way of telling this ResBuf->ObjectList class just what you're expecting so it can check the input against those rules.

[BlackBox]

I'm really struggling to understand this; I'd be remiss if I didn't also point out the irony here.

Some have all but balked at the suggestion that basic Exception handling be implemented in the LispFunction Methods being offered, yet somehow a new, indeterminably complex Class structure to handle each-and-every-single-possible Exception potentiality (which would most assuredly be longer than one page, of unknown font size, font style, and page margins, etc.) is worthwhile?

Would it not be preferable to simply implement basic code logic to throw one or more basic *LispExceptions (i.e., TooFewArgs, TooManyArgs, ArgumentType, etc.), in addition to any custom *LispException Types that derive from same, in order to scrub a given LispFunction Method's ResultBuffer for the required or allowed argument(s)?

Never mind the fact that even if such an all-inclusive Exception handling Class existed, you'd still need sufficient code logic to feed this Type's constructors the appropriate parameters (where you'd normally just throw the aforementioned *LispExceptions).