Topic: LispFunction and signaling an error

[Glenn R]

I've just started delving into the LispFunction attribute and I'm wondering how you would signal an error back to lisp.
For instance, in ARX, I think I used to call acdbFail("Your error message here") and return RSERR from an acedRegFunc'ed command/handler.

This would stop lisp dead with the descriptive message. For example, when you pass the worng number or type of arguments to
an in-built lisp function, it complains heartilly and stops...how do we do the same thing??? PInvoke maybe...

You can imagine, that with the LispFunction signature taking a Resbuf argument, that if that resbuf was null, or had the wrong number or
type of arguments, you would want your function to complain loudly and stop lisp not just return nil for instance.

Any thoughts are welcome.

Cheers,
Glenn.

[LE]

Hola, Glenn;

I have done like three or four lisp function with C#, but have not found a way to test if the arguments in the resbuf are the right ones, as what we can do in ARX.

Like:

ARX - to make sure the function has two arguments and both are ename's

Code: [Select]

if (pArgs && pArgs->restype == RTENAME && pArgs->rbnext && pArgs->rbnext->restype == RTENAME)   
{

}

I have all the returned code values from the adscodes.h (there are some samples in the adesk net forum - from some of the ones that knowns C#)  but have not done any real test as the one above.

And yes for example this function

Code: [Select]

[LispFunction("Summation")]
static public void summation(ResultBuffer args)
{
    Document doc = acadApp.DocumentManager.MdiActiveDocument;
    Editor ed = doc.Editor;
    Dictionary<string, short> openWith = new Dictionary<string, short>();
    IEnumerator it = args.GetEnumerator();
    while (it.MoveNext())
    {
        short ad = 0, num = 0;
        TypedValue val = (TypedValue)it.Current;
        // ignore start or end of list
        short RTLB = 5016, RTLE = 5017;
        if (val.TypeCode == RTLB || val.TypeCode == RTLE) { }
        else
        {
            string sKey = val.Value.ToString();
            it.MoveNext();
            val = (TypedValue)it.Current;
            num = (short)val.Value;
            try
            {
                openWith.Add(sKey, num);
            }
            catch (ArgumentException)
            {
                if (openWith.TryGetValue(sKey, out ad))
                {
                    num = (short)(num + ad);
                    openWith.Remove(sKey);
                    openWith.Add(sKey, num);
                }
            }
        }
    }
    foreach (KeyValuePair<string, short> kvp in openWith)
    {
        ed.WriteMessage("\nKey = {0}, Value = {1}",
            kvp.Key, kvp.Value);
    }
}

If we, don't pass the right argument(s) it will throw something like:

Command: (summation "test")
System.Reflection.TargetInvocationException: Exception has been thrown by the
target of an invocation. ---> System.InvalidOperationException: Operation is
not valid due to the current state of the object.
   at Autodesk.AutoCAD.DatabaseServices.ResultBufferEnumerator.get_Current()
   at
Autodesk.AutoCAD.DatabaseServices.ResultBufferEnumerator.IEnumerator.get_Current
()
   at ClassLibrary.LESQClass.summation(ResultBuffer args) in
C:\Programming\C#\AddTicks17\Class.cs:line 1153
   --- End of inner exception stack trace ---
   at System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[]
arguments, SignatureStruct& sig, MethodAttributes methodAttributes,
RuntimeTypeHandle typeOwner)
   at System.RuntimeMethodHandle.InvokeMethodFast(Object target, Object[]
arguments, Signature sig, MethodAttributes methodAttributes, RuntimeTypeHandle
typeOwner)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags
invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean
skipVisibilityChecks)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags
invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at AcMgCommandClass.InvokeWorker(AcMgCommandClass* , MethodInfo mi, Object
commandObject, Boolean bLispFunction)
   at AcMgCommandClass.Invoke(AcMgCommandClass* ,
gcroot<System::Reflection::MethodInfo ^>* mi, Boolean bLispFunction)
   at Autodesk.AutoCAD.Runtime.TargetInvocationSEHExceptionFilter.InvokeWorker()
   at Autodesk.AutoCAD.Runtime.ExceptionFilter.Invoke(); error: ADS request
error

Because requires a list of list's:

(setq lst (list '("one" 2) '("one" 3) '("two" 4) '("two" 5)))

Now, how do we check if we are passing the above to our function?

There are forms that might help, but I have not gone that far, cause I simple have not needed anything in lisp - But, I am interested in the the know how....

Or inside of the: foreach (TypedValue rb in args) - grab or test what it is needed...

Code: [Select]

            foreach (TypedValue rb in args)
            {
                switch ((LispDataType)rb.TypeCode)
                {
                    case LispDataType.ListBegin:
                        ed.WriteMessage("\nListBegin");
                        break;
                    case LispDataType.ListEnd:
                        ed.WriteMessage("\nListEnd");
                        break;
                    case LispDataType.Text:
                        ed.WriteMessage("\nText");
                        break;
                    case LispDataType.Int16:
                        ed.WriteMessage("\nInt16");
                        break;
                    default:
                        ed.WriteMessage("\nOther [{0}] ", rb.Value);
                        break;
                }
            }
            ed.WriteMessage("\n");

Maybe, if we first use a ResultBufferEnumerator and MoveNext() - verify all the items and once pass the test, use the Reset() and reuse the iterator....

Hope, makes some sense.... if not no problem

[Glenn R]

Luis,

As far as testing the arguments, how about this:

LillyPondCode

[LE]

Luis,

As far as testing the arguments, how about this:

LillyPondCode

Looks like ObjectARX way to me..... good! -

I been always using the enumerator from the ResultBuffer... not the Array - it opens more possibilities.


Thank you for sharing!

[It's Alive!]

How about throwing an exception, instead of forcing one?

Code: [Select]

[LispFunction("Test")]
    static public ResultBuffer errtest(ResultBuffer Rb)
    {
      ResultBuffer RetBuf = new ResultBuffer();

      if (Rb == null)
      {
        throw new Autodesk.AutoCAD.Runtime.Exception
          (ErrorStatus.InvalidInput, "\n.\n** Incorrect Number of Parameters **\n.\n.\n.");
      }

      List<TypedValue> ArgList = new List<TypedValue>(Rb.AsArray());

      if (ArgList.Count != 1)
      {
        throw new Autodesk.AutoCAD.Runtime.Exception
          (ErrorStatus.InvalidInput, "\n.\n** Incorrect Number of Parameters **\n.\n.\n.");
      }

      if (ArgList[0].TypeCode != (int)LispDataType.Text)
      {
        throw new Autodesk.AutoCAD.Runtime.Exception
          (ErrorStatus.InvalidInput, "\n.\n** Parameter 1 should be a string **\n.\n.\n.");
      }

      RetBuf.Add(new TypedValue((int)LispDataType.Text, ArgList[0].Value));

      return RetBuf;
    }


[It's Alive!]

After playing with this for a while, I think that I am more inclined to return nil and generate some sort of an error log.
Who knows what un-freed unmanaged resources / memory leaks might be left behind by ungracefully throwing exceptions.
I also think its better to let the consumer of the function decide how to handle the return value.

Dan

[Kerry]

.............  I also think its better to let the consumer of the function decide how to handle the return value.

Dan

That would be my design model too.

paraphrased : give me back by ball, If you wont play by my rules I'm not playing any longer ..

[Glenn R]

Dan,

Shame on you Throwing a .NET excpetion to lisp!

Seriously, what I was after is the same functionality as autolisp gives.

Ponder the following:

Code: [Select]

Command: (/ 1 0)
; error: divide by zero

NOT this:

Code: [Select]

Command: (test)
Autodesk.AutoCAD.Runtime.Exception:
.
** Incorrect Number of Parameters **
.
.
.
   at CsMgdAcad3.tcgsCommands.errtest(ResultBuffer Rb) in C:\Documents and
Settings\Glenn\My Documents\Visual Studio
2005\Projects\CsMgdAcad3\CsMgdAcad3\Commands.cs:line 50
   at AcMgCommandClass.InvokeWorker(AcMgCommandClass* , MethodInfo mi, Object
commandObject, Boolean bLispFunction)
   at AcMgCommandClass.InvokeWorkerWithExceptionFilter(AcMgCommandClass* ,
MethodInfo mi, Object commandObject, Boolean bLispFunction)
   at AcMgCommandClass.Invoke(AcMgCommandClass* ,
gcroot<System::Reflection::MethodInfo ^>* mi, Boolean bLispFunction)
   at AcMgCommandClass.CommandThunk.InvokeLisp(CommandThunk* ); error: ADS
request error

Hence, my original question - you should NOT just return NIL if there is a serious error preventing you from continuing,
but it should be as 'nice' as the lisp errors are on the command line.

Thanks for taking a look.

Cheers,
Glenn.

[Kerry]

[hint]
ERRNO system variable
[/hint]

(if (and
        returnVal
        (not (zerop ERRNO ))
    )
    (proceed ... 

[It's Alive!]

Dan,

Shame on you Throwing a .NET excpetion to lisp!

Hehe well you said make it complain loudly   

[Glenn R]

Hehe true...that I did and you certianly did

But seriously, I think we still an 'elegant' answer as it were...

[Glenn R]

Kerry,

Regardless of setting ERRNO, that example you gave would still rely on SOMETHING being returned to lisp...that's the point. We want to make lisp stop dead the same way as the inbuilt lisp functions do.

I think....

Cheers,
Glenn.

[It's Alive!]

try this

Code: [Select]

// PostCommand("CANCELCMD");
    [DllImport("acad.exe",CharSet = CharSet.Unicode,
    CallingConvention = CallingConvention.Cdecl,
    EntryPoint = "?acedPostCommand@@YAHPB_W@Z")]
    extern static public int PostCommand(string cmd);

edit:

see this link http://through-the-interface.typepad.com/through_the_interface/2006/08/cancelling_an_a.html

[It's Alive!]

example

Code: [Select]

   // PostCommand("CANCELCMD");
    [DllImport("acad.exe", CharSet = CharSet.Unicode,
    CallingConvention = CallingConvention.Cdecl,
    EntryPoint = "?acedPostCommand@@YAHPB_W@Z")]
    extern static public int PostCommand(string cmd);

    [LispFunction("Test")]
    static public ResultBuffer errtest(ResultBuffer Rb)
    {
      ResultBuffer RetBuf = new ResultBuffer();
      try
      {
        if (Rb == null)
          return MyError("too few arguments");
       
        List<TypedValue> ArgList = new List<TypedValue>(Rb.AsArray());

        if (ArgList.Count > 1)
          return MyError("too many arguments");

        if (ArgList[0].TypeCode != (int)LispDataType.Text)
          return MyError("bad argument type: stringp " + ArgList[0].Value.ToString());

        RetBuf.Add(new TypedValue((int)LispDataType.Text, ArgList[0].Value));
      }
      catch
      {
        return MyError("Automation Error. method TEST  failed.");
      }
      return RetBuf;
    }

    public static ResultBuffer MyError(String str)
    {
      Editor ed = AcadApp.DocumentManager.MdiActiveDocument.Editor;
      ed.WriteMessage("\n; error: " + str + "\n");
      PostCommand("CANCELCMD");
      return null;
    }

Edit: used more lisp like error messages

[LE]

Just for reference - the only information available in the arx docs

Defining Methods That Can Be Called From AutoLISP
 
 

Managed applications can define methods so that they can be called by AutoLISP applications. To do so, the managed application tags the desired method with the Autodesk.AutoCAD.Runtime.LispFunction attribute. This attribute can be used in the same places and has the same properties as the CommandMethod attribute. The key difference lies in the signature form to which LispFunction may be applied. LispFunction is valid only for methods of the form

public ResultType MyHandler(ResultBuffer args) {
...
}
where ResultType can be any one of the following types:

int
double
TypedValue
ResultBuffer
string
Point2d
Point3d
bool
void
ObjectId
SelectionSet
The Autodesk.AutoCAD.Runtime.LispDataType enumeration defines .NET identifiers that represent the data types passed through AutoLISP ResultBuffer arguments.

For instance, the following C# code defines an AutoLISP-callable “Hello World” method:

using Autodesk.AutoCAD.Runtime;
using Autodesk.AutoCAD.EditorInput;
using Autodesk.AutoCAD.ApplicationServices;
...
[lispFunction("c:helloworld")]
public void hw(ResultBuffer args)
{
    Editor ed =
        Application.DocumentManager.MdiActiveDocument.Editor;
    ed.WriteMessage('\n' + "Hello World!" + '\n');
}

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

[LE]

Glenn;

Are you doing a library functions to be use from AutoLisp?

[Glenn R]

Luis,

Of course.

Cheers,
Glenn.

[It's Alive!]

Cool,
I think I’m going try the ‘(nil . exception.message) for a while and
see how it works. Here is a sample output

Command: (ADO:Tools "C:\\NewMDB.mdb" "CREATE DATABASE")
(nil . "Database already exists.")

Command: (ADO:Tools "C:\\NewMDB.mdb" "CREATE TABLE Table1 (Name VARCHAR,
Address VARCHAR, Num INTEGE)")
(nil . "Syntax error in field definition.")

Command: (ADO:Tools "C:\\NewMDB.mdb" "CREATE TABLE Table1 (Name VARCHAR,
Address VARCHAR, Num INTEGER)")
(nil . "Table 'Table1' already exists.")

Code: [Select]

catch (System.Exception ex)
      {
        result.Add(new TypedValue((int)LispDataType.Nil));
        result.Add(new TypedValue((int)LispDataType.DottedPair));
        result.Add(new TypedValue((int)LispDataType.Text,ex.Message));
      }
      return result;


[Kerry]

Cool,
I think I’m going try the ‘(nil . exception.message) for a while and
see how it works. <snip>

Daniel, with the apparent inability to use the 'out' keyword methodology, that seems to be an acceptable way to handle it.
Thanks for the conversation guys ... I'm looking forward to making time to play again.

[Chuck Gabriel]

Sorry to resurrect something so long dead, but have there been any new discoveries in this field?

[Glenn R]

Not by me Chuck...I gave up in disgust. Someone else might though.
Do you have something to share?

[Chuck Gabriel]

Do you have something to share?

Sorry, but no.  I'm just dipping my toes in for the first time and immediately ran into this problem.  If I do come up with something, I'll certainly share it, though.

[Glenn R]

The water's fine...jump in!