13.07.2015 Views

Caché Upgrade Checklists - InterSystems Documentation

Caché Upgrade Checklists - InterSystems Documentation

Caché Upgrade Checklists - InterSystems Documentation

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

DevelopersIf, however, the execution of “Error correction statements” causes an error, then the error from “Some statements” willbe overidden and the enclosing error handler will receive this latter error information. The error that occurred in the TRYblock will not be reported.<strong>InterSystems</strong> recommends that the code be rewritten asTRY {Some statements}CATCH ErrorData{Error correction statements…THROW ErrorData}This ensures that, if the THROW is reached, the error information will be passed to the enclosing error handler. If theexecution of “Error correction statements” causes a failure, this will be reported to the enclosing error handler, but theexception data from the TRY block will still be available for debugging.In the rewritten example, if the error is detected by <strong>Caché</strong>, ErrorData will be an instance of %Exception.SystemException.This class is reserved for use by <strong>Caché</strong>. Applications that wish to provide their own exception data should define subclassesof %Exception.AbstractException and use instances of these subclasses as arguments for the THROW.Note:The main distinction between system exceptions and user exceptions is how they are processed. Instances of%Exception.SystemException will be processed by the nearest enclosing CATCH, $ZTRAP, or $ETRAP statement.User-defined subclasses of %Exception.AbstractException will only be processed by enclosing CATCH statements.If there is no enclosing CATCH, a error will be thrown.Thus, the reason for deprecating the use of THROW without an argument is the difference in the way systemgeneratedversus application-generated exceptions are handled. The use of an argument allows precise controlover the kind of exception process executed.7.2.4.13 Supported MacrosThis version of <strong>Caché</strong> defines the initial set of officially supported ObjectScript macros. These macros will be the onlyones displayed by StudioAssist when the sequence, “$$$”, is recognized during program input. The full set of macros andtheir definition can be displayed via the $SYSTEM.OBJ.ShowMacros method.7.2.4.14 Changes To Compiled CodeThis version of <strong>Caché</strong> eliminates the tokens that were previously generated to mark the beginning of each line source line.The system now keeps track of the number of CacheObjectScript (or CacheBasic, CacheMVBasic, or CacheMV PQ/PQNPROC) statements that have been executed in a manner more efficient than previously.This gives a much more accurate picture of how much work is going on in a routine. In previous versions, blank lines,comment lines, and lines with executable statements on them were all marked with these tokens. This change also freesprogrammers from worrying about the performance effects of writing in a much more readable, modern style, with eachstatement on a separate line, and with ample comments.7.2.4.15 JOB Command Requires Startup DirectoryAmong the “process-params” given to the JOB command is os-directory, a directory the child job should switch to as partof starting up. This is not necessarily the directory the job will use as it may be overridden by the default directory associatedwith the namespace for the child job.In prior versions, errors that occurred in the child job while attempting to switch to the os-directory were not treated consistentlyacross platforms. On Windows and OpenVMS, errors were ignored. On UNIX®, the behavior varied by platform.<strong>Caché</strong> <strong>Upgrade</strong> <strong>Checklists</strong> 177

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!