ObjectScript allows to use macros as statement, as in:

    Method m()
    {
        $$$SOMETHING
    }

or even:

    Method m()
    {
        $$$SOMETHING(with, arguments)
    }

Here, SOMETHING is a macro. The problem is that a macro can expand to anything; for instance (for the argumentless version):

Starting with Caché 2010.1, InterSystems does not document the $ZUTIL function anymore. It is advised that uses of this function be replaced with alternatives.

Please see this URL for a list of replacements.

The $ZORDER function is a legacy function. Newer code should use $QUERY instead.

Links:

ObjectScript allows indirect access to object property values via $PROPERTY, but also to parameters, methods and class methods using $PARAMETER, $METHOD and $CLASSMETHOD respectively.

For instance:

ObjectScript supports try/catch statements. Old code would have to resort to using the $ETRAP system variable, as in:

    new $etrap
    set $etrap = "do somethingElse()"

    // Execute "do somethingElse()" if "do something()" throws an exception
    do something()

This should be replaced with:

Setting the $ECODE special variable is especially confusing and, moreover, dangerous:

• it will throw an exception if and only if the value is not an empty string;
• since this is the SET command, in addition to this, there may also be a postconditional.

As a result, when reading this line:

The QUIT command can be used for three different scenarios in program code:

• exit the method with no value;
• exit the method with a value;
• breaking out of a loop statement, try block or catch block.

As a result, this can lead to code where it is very confusing to actually detect the usage, all the more that the nesting level is deep and the code is long; consider for instance:

Non short circuit operators will evaluate all expressions even if one would normally stop the execution if short circuit operators were used instead.

If the use of such an operator is done on purpose, this is very often an indication that one or more checks in the boolean expression have side effects, which is undesirable. Try and refactor the code so as to avoid the use of such operators.

Using GOTO for control flow is not recommended. Moreover, it can lead to unsuspected runtime failures. Look at this code for instance:

Method m()
{
    goto out;
out(arg)
    write "Writing", arg," and out", !
}

out is really a subroutine embedded in the method, and it expects an argument. Here however, there isn't any, and the failure will not occur until runtime.

In some situations, an application may want to switch namespaces temporarily using, for instance:

    Method m()
    {
        set oldNs = $namespace
        set $namespace = newNs // or: znspace newNs
        do ..something()
        set $namespace = oldNs // or: znspace oldNs
    }

But if the code between namespace changes fails for any reason, the namespace will not be switched back. The solution is to use new $namespace instead: