Unclear on syntax for returning from a lisp function created in c#

Quote:

---

Originally Posted by BlackBox

Respectfully, your own code also returns false (Nil), in lieu of an Exception when no argument is supplied.

---

I see that you've gone back to correct this after I had started my response... Please disregard.

From post #2 of this thread:

Re: Return value of a lisp callable function

Quote:

---

Originally Posted by Tony Tanzillo

A method marked with the LispFunction attribute should return a ResultBuffer only if you are returning a list.

If you are returning an atom, you just return that value directly.

For example, this method will return the symbol T:

Code:

---

[LispFunction("foo")]
public static object Foo( ResultBuffer args )
{
  return true;
}

---

and this will return the integer 99:

Code:

---

[LispFunction("bar")]
public static object Bar( ResultBuffer args )
{
  return 99;
}

---

and this will return the string "Hello":

Code:

---

[LispFunction("baz")]
public static object Baz( ResultBuffer args )
{
  return "Hello";
}

---

IOW, the result of your lisp-callable function does not have to be a ResultBuffer, it can be that, or any value you can put into a TypedValue's Value field as well. The runtime looks at the result and converts it to the appropriate LISP result. In the case of System.Boolean, that would be the symbol T for True, or NIL for False.

You cannot return COM objects to VisualLisp using LispFunction, but you write a COM-callable wrapper that can return COM objects or any other ActiveX compatible type, which can be called from LISP using VLAX-* functions.

---

Quote:

---

You well know that I both respect and admire you, and the work that you've done for this community. I am struggling to understand (perhaps due to a lack of education / experience on my part), as your argument (to me) seems to be one of preference, and not requirement.

I agree that OOTB LispFunctions such as (1+) will throw an error instead of returning Nil, and that it is usually best to mimic the built-in functionality... However, I stand by this being discretionary, and not a mandatory requirement.

If throwing LispExceptions were mandatory, then they would also be hard-coded into the API as is the case with many using directives, etc., and they are not.

---

I agree this is not mandatory and it's not hard coded in the .NET API, but it is in LISP.
If you define the same function as this:

Code:

---

(defun 2x (n) (* 2 n))

---

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.

Your C# code is equivalent to the following LISP function:

Code:

---

(defun 2x (n)
  (if (numberp n)
    (* 2 n)
  )
)

---

Would you write it this way in LISP ?

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).

Re-read the first message, this is exacly what requires JaCAD: an exception thrown (and the end of evaluation) rather than a nil returned.

Quote:

---

Poor coding practices on the part of the user is not justification... This again demonstrates that code logic mitigates Error/Exception handling. I never claimed to mimic built-in functionality, and was quite clear about what the code does.

---

All these arguments checkings are related to what you call "poor coding practices"...

Quote:

---

I would never supply an argument to a function, not even (car (entsel)) without first checking it as being non-Nil before processing a dependent variable.

---

(car (entsel)) may return nil, (abs x) or (sqrt y) never...

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.

Quote:

---

Originally Posted by 'gile'

I agree this is not mandatory and it's not hard coded in the .NET API, but it is in LISP.

---

Respectfully, nothing after this sentence is helpful to this thread, and you are correct.

I have already conceded to your point that other built-in LispFunctions (specifically those for math operations) do not return Nil, which should be a best practice. I refuse to argue a matter of preference, given that each LispFunction a given user will code for themselves is task dependent.

Should the OP, who hasn't posted since starting this thread, have any questions, I am confident that you will offer sound advice, as I have personally learned a great deal from you in the past.

Quote:

---

Originally Posted by 'gile'

Hi,


It returns nil because your error handlers ends with: "return null;".
To avoid this, you can re-throw the exception after having displayed the error message:

Code:

---

catch (LispException ex)
            {
                MgdAcApplication.ShowAlertDialog(ex.Message);
                throw;
            }

            catch (Autodesk.AutoCAD.Runtime.Exception ex)
            {
                MgdAcApplication.ShowAlertDialog(ex.Message);
                throw;
            }

            catch (System.Exception ex)
            {
                MgdAcApplication.ShowAlertDialog(ex.Message);
                throw;
            }

---

PS: BlackBox, your adaptation should always return nil in case an exception is raised (nil stands for false too).

---

Thanks Gile, this is the functionality I was looking for. Thanks also for your LispException classes.

Is there a way to suppress the error stack which dumps to the command prompt in the instance of an exception?

Thanks!

Quote:

---

Is there a way to suppress the error stack which dumps to the command prompt in the instance of an exception?

---

Maybe, but I don't know which. That's why I use the Application.ShowAlertDialog() method to prevent the user/coder that an error occured.

Quote:

---

Originally Posted by BlackBox

This again demonstrates that code logic mitigates Error/Exception handling.

---

I do not think that is a good idea to practice.

I know nothing about AutoLisp or .NET either, but I would think like Gile said should only return nil if valid return type.
If a function needs to return nil how would you know if it really evaluated to nil or was from invalid input, etc....


I guess since the Interface between .Net and AutoLisp is through a function that can basically take a param object[] and returns a object you can pass in and back anything and removes the ability to define a strongly typed signature.

Maybe wrapping the function call to .NET function in another lisp function might help some by at least requiring how many arguments should be passed in.

Gile -

I just wanted to say thanks for you help in this thread; back when I made my original comments here I didn't realize just how stubborn, and incorrect I was. I had an opportunity today to share your informative comments with another member, which really clarified my position (as I agreed with you, as I neglected to do back then).

Thanks again for all that you've done, and continue to do for this community, mon ami. :beer:

Cheers