Limitations of Catch_Error

Won't work to catch cross section naming errors when using CREATE_XSEC. I know that one 🙂

Design well!

Hi Scot,

The easiest way to know what commands allow error trapping is to look for the "Error Handling" argument in the Admin Guide. Any command that does NOT contain a note about error handling does not allow for error trapping.

You are correct that syntax error's can not be trapped in the error handling. To be honest I'm not sure why you'd want to bypass a syntax error, because if a line doesn't contain the proper syntax, it can't be run and is useless to you.

Joel Beckley

Application Engineer

SIGMAXIM

In Reply to Scot Zundel:

Does anybody know of a resource that discusses the limitations ofBegin_Catch_Error command? If not, I plan on testing what errors can be caught and what errors cannot be caught.

One example that cannot be caught is a syntax error.

Thanks,

Scot

I should rephrase what I am looking for.

I am looking for a reference or discussion about best practices for Error Handling within SmartAssembly. I would prefer not to enclose my entire code within Catch_Error, but I am not sure what the best practices are.

I tend to use error catching in two ways: when I want to ignore an error, and when I want to catch an error and decide what I need to do with it. For example, if I have a set of features that may or may not all exist across a family of models, I can search for all of those features in any individual model and not have an error thrown if one of those features does not exist:

BEGIN_CATCH_ERROR

SEARCH_MDL_REF myPart FEATURE "FEATURE_A" featA

SEARCH_MDL_REF myPart FEATURE "FEATURE_B" featB

SEARCH_MDL_REF myPart FEATURE "FEATURE_C" featC

END_CATCH_ERROR

Features A, B, and C may not exist concurrently, but I can grab all, some, or even none of them, if none of them exist, without SmartAssembly throwing an error. Later on in the script, I would use the REF_VALID option to control any other commands that might try to access a non-existent reference. Alternatively, you can use the SEARCH_MDL_REFS command and check array sizes and/or write FOR loops for the arrays (SEARCH_MDL_REFS never errors out, it will just create an array of size 0 if it cannot find anything, and any FOR loop for an array of size 0 is effectively ignored without erroring out).

Another place where I tend to use error catching is with UDF creation. Sometimes, I'll be creating a UDF on a cylindrical surface, and the UDF only needs one of the half surfaces to work, but will not work if you don't pass the correct one. In the snippet below, mySurf1 and mySurf2 are the two half surfaces of a cylinder. This code will try the UDF on mySurf1, but if it fails, it will then move on to try placing it on mySurf2.

BEGIN_CATCH_ERROR

CREATE_UDF my_udf.gph myPart myUDF

UDF_REF REF_SURF mySurf2

END_CREATE_UDF

END_IF

Note the use of CLEAR_CATCH_ERROR to allow me to use error catching later on in the script if needed. Also note that there is no error catching of the second CREATE_UDF command, because I want to know if it fails at this point. I could error catch on the second and notify the user that the UDF failed to create and ask them if they want to continue, etc. There's lots of options. I also use error catching in this way to look for pre-existing features needed by the script and see if I need to create them or not.

Is this helpful? I'd be interested to see other uses of error catching if anyone has some to share.

--Geoff

Another way I have used it isfor closing a specific Excel file without closing other Excel files that a designer might have open in the background. If you try to activate an Excel file that is not open, SA gives an error. If there is no error, I know the file is open and then can close only that file.

BEGIN_CATCH_ERROR
EXCEL_ACTIVATE_DOCUMENT "RELATIONS_ERRORS.xlsx"
IF NOT ERROR
EXCEL_CLOSE_DOCUMENT
END_IF
END_CATCH_ERROR

Rick.

Geoffrey's description is pretty accurate with the way we do things. You need to break error trapping into categories. For example:

1 - Is the item I'm working with a searchable item? If so, can that search ever come back null?

2 - Is there a chance that the user could select the wrong item? Catching an error might not actually provide you with that information. You may need additional process steps to mitigate for those circumstances.

3 - Are there more than 1 possible solutions for my geometry creation? Using error trapping can allow you to sort through UDF's that may fail and replace with ones that are stable.

Personally, I tend to wait until the very last minute to start putting error trapping in place. Once I have the script working the way I want it, I look at each place where an error could occur, and then mitigate for it. How the errors are handled are a question of how you want the application to procede.

1 - Do you want the error to be ignored entirely?

2 - Do you want the faulty process step to be replaced by another process step?

3 - Do you want to alert the user and then provide them with options?

4 - Do you want the error to be caught in a log file, and then continue on in the application?

All of these are important questions you have to ask yourself when you're trapping errors. Don't just blanket error trap the entire application, you may be getting errors that you're not even aware of that could seriously alter the output of the application!

Joel Beckley

Application Engineer

SIGMAXIM