Cache for Windows (x86-64) 2016.1.1

sure, many times

I did this test before posting my question to see if the overloading stops the copying.  It does stop and I see compiler generates code like 

q ##class(A)$this.Abc()

but  this way can not be seen as solution because this trick must be done for each such method in each derived class
 

John,  because of debugging:

- you set breakpoint in A.Abc() but it never hit because cache executes B.Abc()

- because of some reason, debuger is not able to step in nether of the copies

Please check my update. Any comments?

Indeed, the documentation of ##Expression describes the behaviour and ##SafeExpression avoids the copying.

Many thanks, Eduard!

That's perfectly OK for my objective: all I need, is just a text like "location of your exception is <location>". Will <location> be A.Abc or B.Abc doesn't really matter.

I had a problem with $classname in some situations but I'll recheck it. Thank you.

That's too complicated for my needs. I export with my own tool so it would be easier to change the tool to clear breakpoints before the export

It will but with two nuances:

- ^%oddENV("callererrorinfo") must be set

- the format could be a bit cryptic, like 

Location = "zrun+3^digi.test.main.1"

while my home made location will says "assertion XYZ failed in digi.test.mai.run"

BTW: can you tell what UI/api is supposes for setting values of ^%oddENV, in particular "callererrorinfo"?

here is one real example of my self backed location:

<EXCEPTION>
assertion failed: digi.chimport.debugMakeStatus: invalid param: 'acc' stack:
zthrowif+2^digi.core.AssertException.1 +1
zdebugMakeStatus+7^digi.chimport.1 +1
ztestChImport+43^digi.test.main.1 +1
%DispatchClassMethod+8^digi.test.framework.1 +1
zdoall+11^digi.test.main.1 +1
zrun+3^digi.test.main.1 +1
zDebugStub+30^%Debugger.System.1 +2
</EXCEPTION>

sorry, not sure what you mean. please elaborate

Looks interesting, thanks for sharing.

What is your problem with breakpoints? As I recall, they are just a collection property of Project object, so you shouldn't have any problems at least to clear them.

BTW: why it is important for you to have project items sorted alphabetically?

I don't like idea to set breakpoints in source code. At least because once set, you have to remember to remove it. This way is the only way for hardcore OS-level debugging but for application programming today I would prefer adequate debugger

The 'crash' is my post is actually incorrect. Studio never crashes, it always stops responding. So no error codes.

Now it took me about 15 minutes to reproduce the problem. I placed several breakpoints in my code and randomly clicked the stack every time debugger stopped, and at first everything worked OK. But then, without any evident reason, Studio stopped responding. Process info reports this:

Execution Details

Process State: EVTW

In Transaction:

No

Last Global Reference:

%apiOLE("debug")

Routine:

%Debugger.System.1

Location:

Source Location:

+415^%Debugger.System.1

Source Line:

I refreshed the page several times, the info remains the same

"I don't tend to use the call stack view"

I'm not able to comprehend that In my world stack view is as natural as.. as... as... I don't know, there is nothing more natural as working stack view in any debugger.

The trick with LOG^%ETN is for a case when you need the stack saved to a diagnostic log. But usual case for stack view is you have your debugger stopped on a breakpoint in some library routine and want to know what path brought you here. What you do? I look at stack view and click it to navigate to a call place.

Cache for Windows (x86-64) 2016.1