[Closed] error checking methods

This is not exactly “error checking”, this is called “idiot proofing”
There isn’t much about it in the help because there are so many ways a user can screw up that it is a whole art (and science) to prevent him from doing it and would require a whole separate help just for that…

As mentioned already in this thread, you can test at superclass level whether an object is of geometry superclass, helper superclass etc. But even these checks have some special cases. For example, when checking for SuperClassOf obj == GeometryClass, you have to also add AND classof obj != TargetObject because a TargetObject is a geometryClass object, but DOES NOT have a valid mesh and will crash most of your scripts. This problem has pre-MAXScript roots and you just have to know about it.

In addition to checking using classof() and superclassof(), you can also perform checks for properties – in other words, making sure an object has a specific property exposed. The two methods hasProperty() and isProperty() can be used to check whether a property is exposed or whether it is accessible.
For example,

if isProperty obj #radius do…

will make sure that obj has a property called .radius you could access…

Still, in a system as complex as Max, there are so many cases that you could miss it is not even funny. Did you know that a scene node might NOT have a .pos property exposed under some circumstances? For example, if you create a Daylight System controlled by the Solar_Time controller, that controller is a Transform Controller but does NOT expose a .position track, thus calling $.pos causes an error, but $.transform.row4 does not because ANY scene node has a transformation matrix, regardless of the controller that is assigned to manage it…

In cases you expect things to go wrong, you might use try()catch() to catch anything that you might have forgotten, but keep in mind that this could “mask” some genuine code errors you might have embedded in your script. So add the try()catch() as a last resort once you have made sure that your script is as bug-free as humanly possible…

try()catch() can fail silently.

For instance instead of checking to see if an object exists before deleting it… You can just throw it in a try()catch() and if it exists it’ll get deleted… otherwise… you can carry on as normal.

I have some routines which are very very fragile and require dozens of conditions to be met before they can proceed. Instead of 30 if/then logic trees I can just put it all in a try() and if all the variables are defined properly it’ll do it’s thing. Other wise it’ll just log it, skip it and move on.

But like bobo said, definitely something you do as a last step. Otherwise you won’t necessarily see what’s going wrong.

Also really helpful because it’ll preview the execution before starting in on it. So if it does fail you can just throw up one error message and call it a day. With a dozen if/then statements it might start doing some prep operations which and then crash leaving open a ton of variables, transformations and what not all over the place.