Topic: LispFunction and signaling an error

[Glenn R]

Nice try Dan, but let's say you did this:

Code: [Select]

(setq a 10)
(setq a (test))

With normal lisp error behaviour, a would still be 10 as (setq a (test)) would have failed.
However, you're still returning nil, so now a is nil, rather than remaining 10...see what I mean?

Luis,

Thanks. You can also add object as a return type as it can b0x anything because it's the base calss of everything.

Cheers,
Glenn.

[Kerry]

With normal lisp error behavior, a would still be 10 as (setq a (test)) would have failed.

It may be time for definition of terms and concepts.

normal lisp error behavior
would depend on the design , yes ?
... the discussion regarding parameter validation in most cases depends on the philosophy of the designer.

a would still be 10 as (setq a (test)) would have failed
again, would depend on design.

The typical paradigm is that where return values are expected the return value will be either valid or nil.
.. particularly in an assignment statement
This could become a really complicated thread if we get into a discussion about data assertion testing.

.. .. and I suppose the decision regarding how recoverable or otherwise the error is will determine the subsequent handling.

[Kerry]

Nice try Dan, but let's say you did this:

Code: [Select]

(setq a 10)
(setq a (test))
< snip>
However, you're still returning nil, so now a is nil, rather than remaining 10...see what I mean?

Cheers,
Glenn.

How about something like :-

Code: [Select]

(setq a 10)
(if (and (setq tmp (test))
           (somehowvalidate tmp)
    )
    (setq a tmp)
)


[It's Alive!]

The problem is that lisp is not evaluating (test) but merely passing back the value of an external function. I believe ARX handle this the same way? I.e

Code: [Select]

(setq a 10)
(setq a(dos_strtrim))
Produces the same results (a is nil). The Code I posted was the only way I know of, to stop a lisp that’s in a loop.

Code: [Select]

(repeat 10 (princ(setq a(dos_strtrim))))
Produces
nilnilnilnilnilnilnilnilnilnilnil
Where

Code: [Select]

(repeat 10 (princ(setq a(test))))
; error: too few arguments
; error: Function cancelled
well at least this stops the lisp engine, similar to how lisp would handle this.

If the goal is to stop lisp, then does preserving the value of  !a really matter?
Most likely it would be a local variable and destroyed anyway.

[Glenn R]

would depend on the design , yes ?

...and the design in question is AutoCAD's. Example:

Code: [Select]

(setq a (/ 1 0))

or for that matter:

Code: [Select]

(setq a (/ "somestring" 2))

Both provide an error and stop evaluatiion.

The typical paradigm is that where return values are expected the return value will be either valid or nil.
.. particularly in an assignment statement

The code snips above say otherwise there Kerry.

[Kerry]

Sorry Glenn, I was comparing apples to eggs ...
my observations were related to lisp defined functions.

If you can post some CPP code that behaves the way you expect and some notes I'll pass it on to ADN.

kwb

[It's Alive!]

Well now I’m curious,
Can someone describe for me, why someone would want to re-use the value of a lisp variable in this scenario?
Call me limited…

[Glenn R]

Dan,

It's got nothing to do with preserving the value of the lisp variable - that was just a side effect of the current behaviour. However, it has EVERYTHING to do with designing your code/programs/applications to mimic the functionality already provided and set down as a standard...in this case, the AutoCAD AutoLISP environment itself.

Kerry,

I'm starting to think the implementation is substantially different from the ARX model. In ARX, you define your external command as returning an int. You would then process the resulttbuffer arguments you were passed (if this is your design) and if they are not what was expected, you simply return an ARX error code - RTERROR for example.

If, however, all your passed args were ridgy-didge, you would then do your mojo and use the appropriate value return function (acedRetInt(), acedRetReal(), acedRetList() etc.) to return to lisp the data it needed.

So you see, your function returns an int, but you use a special value return function for lisp - this does not appear to be how the LispFunction attribute is designed to work, so returning nil might be the only course of action.

[Kerry]

Would it be possible to return a list,
The first element would be an ErrorCode [ ERRNO ] or 0 ( a mentioned elsewhere )
and subsequent items in teh list would be the required return value.

[Glenn R]

Kerry,

I think it would be easier to return nil if we are to return anything to autoLisp...thoughts?

Cheers,
Glenn.

[Kerry]

Hi Glenn,

I think it depends on how much information we want to feed back to the user.
Exception advice could be offered from the assembly ... how much use that would be to the average user other than a 'comfort message' I don't know ... I 'spose it depends if it's a user error or one that we don't want to discuss that may reflect on our lack of planning regarding allowing for parameter checking.


.. there is then the requirement to run any error trap routine from lisp to restore/rollback system variables etc for 'acceptable housekeeping'

[Glenn R]

Kerry,

Agreed. the exception route is out of the question from previous tests on this thread. Unless we hear from somebody else with a better implementation, I think NIL is the way to go, more's the pity.

[It's Alive!]

Having done a few of these for my own use, here are some of my thoughts.
First, an external program should never “stop” my lisp routines, send me something
I can handle, a nil , and error code, something I can test against and decide what path to take.
Next, I don’t think external programs have any business writing error messages to the prompt.
Having said this, sometimes passing back just a nil can leave the end user clueless as to
where/what the problem is. Lets use my ADO:Tools routine for an example
http://www.theswamp.org/index.php?topic=12077.msg186641#msg186641

It returns ‘(nil)  on all errors, which s*cks, when trying to debug SQL statements.
Maybe a better design would be to return ‘(nil . Exception::ToString())
or nil and an error log file,
or nil and assigning a global variable i.e. *ADO:Tools*  with the last error message.

Maybe some lisp users could chime in on this.

[T.Willey]

If I was to use an external function within lisp, I would not expect it to error unless given arguments that don't fit it.  If it expected int's, and I gave it a string, then I would expect an error, but if I gave it the right arguments then I would expect a value or nil returned.  This is how I code my sub functions within any language.

[Glenn R]

If it expected int's, and I gave it a string, then I would expect an error, but if I gave it the right arguments then I would expect a value or nil returned.

Exactly my point Tim.