|
|
|
"How we think determines what we do, and what we do determines what we get."
Sincpac C3D ~ Autodesk Exchange Apps
Computer Specs:
Dell Precision 3660, Core i9-12900K 5.2GHz, 64GB DDR5 RAM, PCIe 4.0 M.2 SSD (RAID 0), 16GB NVIDIA RTX A4000
From post #2 of this thread:
Re: Return value of a lisp callable function
Originally Posted by Tony Tanzillo
"How we think determines what we do, and what we do determines what we get."
Sincpac C3D ~ Autodesk Exchange Apps
Computer Specs:
Dell Precision 3660, Core i9-12900K 5.2GHz, 64GB DDR5 RAM, PCIe 4.0 M.2 SSD (RAID 0), 16GB NVIDIA RTX A4000
I agree this is not mandatory and it's not hard coded in the .NET API, but it is in LISP.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.
If you define the same function as this:
An exception will be thrown if there's more or less than one argument or if a non-number is passed to 2x.Code:(defun 2x (n) (* 2 n))
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:
Would you write it this way in LISP ?Code:(defun 2x (n) (if (numberp n) (* 2 n) ) )
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.
All these arguments checkings are related to what you call "poor coding practices"...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.
(car (entsel)) may return nil, (abs x) or (sqrt y) never...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.
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.
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.
"How we think determines what we do, and what we do determines what we get."
Sincpac C3D ~ Autodesk Exchange Apps
Computer Specs:
Dell Precision 3660, Core i9-12900K 5.2GHz, 64GB DDR5 RAM, PCIe 4.0 M.2 SSD (RAID 0), 16GB NVIDIA RTX A4000
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.Is there a way to suppress the error stack which dumps to the command prompt in the instance of an exception?
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.
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 3660, Core i9-12900K 5.2GHz, 64GB DDR5 RAM, PCIe 4.0 M.2 SSD (RAID 0), 16GB NVIDIA RTX A4000