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

[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

[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=

[peter]

IMHO

I write code in a work environment while working on drafting projects, and use them immediately.

I am sure since 1986 I have coded way more than 5000 functions for AutoCAD.

These are my priorities when programming for AutoCAD or anything else.

I have always coded while I am drafting real jobs not test drawings as a part of my work.

1.) Protect the Drawing Database... Crashes can corrupt databases and loose valuable time restoring them, avoiding crashes is absolutely imperative.

2.) It follows the I protect the routine. Crashes cost time and time is money. If I can make it so a routine is almost bullet proof to crashing, I am saving time.

3.) Exception handling is not necessary for a function to work, unless a function is used incorrectly, and since I code them and use them immediately I rarely need exception handling for new functions.

4.) For toolbox functions that are used regularly and are used after the time of creation, I add exception handling.

5.) The value of a function is based on a simple calculation "time of development" + "sum or runtimes" < "time to manually accomplishing same work"

6.) Most of my code takes me 10 minutes to code and use.

7.) I am practicing my vb.net programming to get it down to 10 minutes... it is around 20 minutes per function now.

8.) I find adding exception handling doubles the amount of time invested in a routine...
I am always calculating the time and money to see if it is worth adding.

9.) Exception handling also makes the routine more complicated, so when making simple examples,
I leave it out because if used correctly the function will work without it.

10.) I also protect the function by ignoring extra arguments, converting arguments
to string (when strings are required), etc...

This kind of development is different than the kind where programmers are paid
to develop full time and run on a different set of priorities.

If you examine your priorities, you may find they are different than mine, and
that may make exception handling more of a priority for you.

I am familiar with gile, kerry and tt and they all have different styles and
priorities that affect their programming style.

I think you would have difficulty getting any group of programmers to agree
on anything, let alone mix Microsoft in on the discussion.

If you think my code is lacking because of the simplicity in it,
feel free to modify and re-post in your preferred style...

It doesn't hurt my feelings.

There is no one right way of doing this... Do what works for you.

P=

[BlackBox]

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=

Found it, thanks.