Guilherme Mendes · Dec 13, 2022

Ignore BREAKs


I'm running a unit test via terminal, and sometimes someone from another team/squad add a few BREAKs and my tests stop until I skip one by one.

Is there a way to ignore BREAKs?

Product version: Caché 2018.1
0 179
Discussion (7)2
Log in or sign up to continue

Use BREAK with a postcondition depending on Username 
or some other personal switch (eg. PPG)

If you have just a few breaks, one of the possible solutions has been given by Robert CemperIn case, you have tons of those breaks, you could execute the unit test in background:

job ^performUnitTest

assumed, your unittest can work in background and all the output goes, for example, in a file.

The solution for the case you let run the unittest in a terminal session, could be something like this

do turnOffBreaks, performUnitTest, turnOnBreaks

The only problem is, to turn breaks off (or on), you need one view command, one $view() function and one $zutil() function (to get the right address for the view-s). Unfortunatelly, the use of the above tools is discouraged, so your best bet is, to ask WRC for a help.

That's one of the very good reasons, do not work together on the same server. So, yeah, the best way to go is to use your own instance, so, no one will break your tests excepts you

Disable breaks for a current process by calling $system.Process.BreakMode(0). Docs.

To disable breaks system-wide set the BreakMode property in the Config.Miscellaneous class.

That has eluded me (so far). Thank you for the hint.

It might be easier just to always make your BREAK commands conditional like (Robert Cemper suggests above).  Do it like:


Use your own name for "MyName".

Then you do SET ^|"USER"|MyNameBreakAppEnable=1 to enable break points and
KILL ^|"USER"|MyNameBreakAppEnable to turn break points off.

Change the name of "App" to conditionalize break points for use in different applications.  And "USER" is a scratch namespace available on all the instances you plan to do debugging on.

Discourage the use of hard coded breaks in the first place! There are alternatives.

  • Use ZBREAK Tag+OffSet^Routine to set a break point just for the current process
  • Use the debugger in Cache´ Studio (under the Debug menu and attach to a process)
  • George James has a decent debugger in Serenjii
  • Put something in your processes to remove hard coded break points when you promote code through the development cycle (you can automate this if you try)