Debugging is the process of finding and resolving defects or problems within a computer program that prevents the correct operation of computer software or a system.
In the WRC, we often see customers who have encountered a problem viewing their SOAP Catalog pages in a browser. This article will explain why the error is being encountered, as well as suggest a fix. This explanation is focused on the symptoms seen in InterSystems IRIS, but similar behavior can be seen in more recent versions of Caché.
InterSystems ObjectScript is perhaps the best language on the planet to deal with globals - and it is an interpretable language.
Yes, it has a compiler. But even the compiler can compile some lines in ObjectScript which will then fire as bugs during the runtime.
There are some technics on how to avoid that such as unit testing, coding guidelines and your coding experience, of course ;)
Here I want to present to you the yet another approach to how you can reduce the number of errors in your ObjectScript runtime and enforce coding guidelines - it's an ObjectScript Quality tool developed by Lite Solutions, InterSystems solution partner.
Hi, if you develop production with HealthShare, you may have noticed there is a nice tracing feature available - HS.Util.Trace.Operations. This feature allows visually tracing debug information, in structured way. It complements good old logging macros like $$$LOGINFO, $$$TRACE and alike.
I use this feature a lot. However, it has limited functionality, it works nice with classes that extend XML Adapter, streams or data types, but it doesn't work well with arbitrary objects that do no extend from XML Adapter.
Every developer has made the mistake of accidentally leaving temporary debug code in place when they meant to remove it after debugging is complete. The great thing about writing in ObjectScript is that there is a way to make temporary code be truly temporary and automatically self-destruct! This can also be done in such a way that the code has no change of making it into your source control stream, which can be helpful as well.
This is more for my memory that anything else but I thought I'd share it because it often comes up in comments, but is not in the InterSystems documentation.
There is a wonderful utility called ^REDEBUG that increases the level of logging going into mgr\cconsole.log.
Not everyone knows that InterSystems Caché has a built-in tool for code profiling called Caché Monitor.
Its main purpose (obviously) is the collection of statistics for programs running in Caché. It can provide statistics by program, as well as detailed Line-by-Line statistics for each program.
Using Caché Monitor
Let’s take a look at a potential use case for Caché Monitor and its key features. So, in order to start the profiler, you need to go to the terminal and switch to the namespace that you want to monitor, then launch the %SYS.MONLBL system routine:
One of the most important features during application development is the ability to debug your code easily. Because of the asynchrnous nature, a standard Node.js application server works single-threaded by default. When you are developing applications using an IDE like Visual Studio Code, you can very easily debug your Node.js process:
The article makes an attempt to demonstrate that Atelier is not just repeating the functionality of Caché Studio on a new IDE platform (Eclipse) but goes far beyond. Due to my personal experience, and challenges in former projects I picked first XSLT Debugging. Is it an ordinary task? Not at all. Who is doing XSLT every day? Probably none of us. Than why XSLT Debugging? Simply because there are solutions in our product portfolio which are using XSLT inside and those solutions require customization. Customizing XSLT without some sort of toolkit is more than challenging. The examples of such solutions starts with HealthShare IHE message, CDA vs. SDA transformations, goes through ZEN Reports, and ends by HealthShare CDA document viewer. Is that enough reason to spend time reading the whole article through not just the teaser?
This post is meant to provide a quick possible explanation for a very perplexing problem.
Scenario: You’ve just created your own administrative user in your 2014.1 (or later) instance of Caché. You gave it every possible security role (including %All), so it should in theory be able to do anything within the instance.
You’ve written a very advanced routine with a break command in it for debugging: