Topic: Trapping a specific Autocad error

[Keith Brown]

I have a block of code where I am grabbing input from the user inside a try/catch block.  I am specifically catching Autocad errors by looking for an Autodesk.Autocad.Runtime.Exception.  When the user inputs an invalid key name for a dictionary such as "\" an autocad error will get thrown.  Specifially the error message in an eInvalidKey.  Like I said I am trapping this error and outputting a message to the command line but I was wondering why I could not specifically catch this error.  I tried catching the eInvalidKey exception but that code did not compile.  I used the following line.

Code - C#: [Select]

1. catch (eInvalidKey ex)

Is it possible to catch specific Autocad exceptions or can you only catch the most general one?

[n.yuan]

eInvalidKey is not a managed type of Exception, so you cannot do

Code: [Select]

try
{...}
catch (eInvalidKey ex){...}

Autodesk.AutoCAD.Runtime.Exception is derived from System.Exception and it wraps up the undeline C++ unmanaged error mechnism. It has a property ErrorStatus, which indicates what C++ error the code runs into. So, you would do:

Code: [Select]

try
{
...
}
catch(Autodesk.AutoCAD.Runtime.Exception aex)
{
    if (aex.ErrorStatus=ErrorStatus.InvalidKey)
    {
        Application.ShowAlertDialog("Wrong dictionary key!");
    }
    else if (...)
    {

    }
}
catch(System.Exception ex)
{
    //If the exception is not a Autodesk's runtime exception, you
    //would catch it here with the generic Exception type as argument
}

[Keith Brown]

That is exactly what I ended up doing.  I just wanted to be sure I wasnt missing something.  Thanks for the reply.

[owenwengerd]

If your handler doesn't handle the particular Runtime.Exception (i.e. it's a different ErroStatus value), then you need to rethrow it, otherwise you won't know there was an exception and that's a VERY BAD THING.

[TheMaster]

That is exactly what I ended up doing.  I just wanted to be sure I wasnt missing something.  Thanks for the reply.

I try to avoid relying on exceptions to validate user input.  In this case it's not terribly difficult to do:

Code - C#: [Select]

1.  
2.    static readonly char[] invalidDictKeyChars = new char[]{
3.       '|', '*', '\\', ':', ';', '>', '<', '?', '"', ',', '=', '`'
4.    };
5.  
6.    // doesn't allow 'anonymous' keys:
7.    public static bool IsDictionaryKeyValid( string key )
8.    {
9.       return !string.IsNullOrWhiteSpace( key )
10.          && key.IndexOfAny( invalidDictKeyChars ) < 0;
11.    }
12.  
13.  

[Jeff H]

I try to avoid relying on exceptions to validate user input. 

I think that's what the methods of SymbolUtilityServices like ValidateCompatibleSymbolName, etc....., do as in throws an exceptions instead of return a bool or some other meaningful value.


Man I was wasting some memory,
I was creating an array of bools like bool[1++] or however many up to highest number for char that could be entered on the keyboard  and defaulting them to false then using the chars as the index to set the index for invalid chars to true. The little boost in efficiency is probably not worth the memory used.
Do not have it in front of me but something like

Code: [Select]


        static bool[] invalidChars = new bool[126];
        static PooClass()
        {
            invalidChars['|'] = true;
            invalidChars[','] = true;
            etc....
        }
I think its time to update to something like Tony example.


Also to throw it out there for creating methods for validating names for Dictionaries and SymbolTableRecord names  there are some 'gotchas' for AutoCAD's standards containers you would think follow the normal pattern but do not.
I will see if I can dig them back up but like Group names can never be more 32 characters long and does not matter what  EXTNAMES is set to, among some other.

[Keith Brown]

That is exactly what I ended up doing.  I just wanted to be sure I wasnt missing something.  Thanks for the reply.

I try to avoid relying on exceptions to validate user input.  In this case it's not terribly difficult to do:

Code - C#: [Select]

1.  
2.    static readonly char[] invalidDictKeyChars = new char[]{
3.       '|', '*', '\\', ':', ';', '>', '<', '?', '"', ',', '=', '`'
4.    };
5.  
6.    // doesn't allow 'anonymous' keys:
7.    public static bool IsDictionaryKeyValid( string key )
8.    {
9.       return !string.IsNullOrWhiteSpace( key )
10.          && key.IndexOfAny( invalidDictKeyChars ) < 0;
11.    }
12.  
13.  

Thanks Tony.  I started to create something to check input and thought that just trapping the error would be "easier".  "Easier" is of course not better.  Your solution is much more elegant than the monstrosity that I was creating.

Owen,  if I am catching the error in a try/catch block located in my command, wouldnt throwing the exception up the call stack just return it to autocad?  If so is that a good idea?

[owenwengerd]

Owen,  if I am catching the error in a try/catch block located in my command, wouldnt throwing the exception up the call stack just return it to autocad?  If so is that a good idea?

Yes, it would, and yes, that is a good idea. Your goal should always be for exceptions (or other unexpected conditions) to be detected as soon as possible. If you can properly handle the exception and continue executing code, that's fine, but if you can't, you should never allow execution to continue while things are in an unknown state.

[TheMaster]

That is exactly what I ended up doing.  I just wanted to be sure I wasnt missing something.  Thanks for the reply.

I try to avoid relying on exceptions to validate user input.  In this case it's not terribly difficult to do:

Code - C#: [Select]

1.  
2.    static readonly char[] invalidDictKeyChars = new char[]{
3.       '|', '*', '\\', ':', ';', '>', '<', '?', '"', ',', '=', '`'
4.    };
5.  
6.    // doesn't allow 'anonymous' keys:
7.    public static bool IsDictionaryKeyValid( string key )
8.    {
9.       return !string.IsNullOrWhiteSpace( key )
10.          && key.IndexOfAny( invalidDictKeyChars ) < 0;
11.    }
12.  
13.  

Thanks Tony.  I started to create something to check input and thought that just trapping the error would be "easier".  "Easier" is of course not better.  Your solution is much more elegant than the monstrosity that I was creating.

Owen,  if I am catching the error in a try/catch block located in my command, wouldnt throwing the exception up the call stack just return it to autocad?  If so is that a good idea?

Exception handling in CommandMethod and LispFunction handlers is not optional, it is mandatory to ensure that AutoCAD doesn't crash.

The AutoCAD managed runtime will only catch CLR exceptions, but will not catch exceptions that are detected at the hardware level (e.g., null pointer, access violation, stack overflow are the most common), which end up being handled by AutoCAD's default exception handler, which of course, simply terminates the process.