Recent posts:
Gertjan has not published any posts yet.
Recent replies:

As you're using Ensemble, you can use class EnsLib.EDI.XML.Document. I don't have version 2015, but the following works on IRIS. I hope this is present in Ensemble 2015 as well. (Note that, annoyingly, method domGetValueAt is marked internal, and therefore doesn't show up in the documentation. I don't know how to achieve the same result without using this method.)

Set XML = "<a><b><c>some content</c></b></a>"
Set Path = "/a/b"
Set Doc = ##class(EnsLib.EDI.XML.Document).ImportFromString(XML, .sc)
If 'sc Quit $System.Status.DisplayError(sc)
Set sc = Doc.domGetValueAt(.Value, Path, "fo", 1)
If 'sc Quit $System.Status.DisplayError(sc)
Write Value,!

This outputs "<b><c>some content</c></b>" as you want.

Hope this helps,

I don't know if try/catch is slow, and I don't care. I don't use it because it is too wordy to handle errors exactly where they occur. It encourages code like in your example, where the code in methods is wrapped entirely in a try/catch block. You say the error object has all the information, but I disagree. It has some low-level information, but often lacks the context I need to determine what the problem is.

My preferred way of handling %Status errors is to add a %Status in front of it with more details of what happened when the error occurred, and return this to the caller. Somewhere up the call chain something will then handle the problem, e.g. add something to the Ensemble event log. This is such a standard way of working for me that I created a macro specifically for prefixing the new status information.

For errors that "raise" I also prefer $ZTrap+$ZError; I don't see the added value of try/catch here either.

I use %Status exclusively; I really, really don't like try/catch. The most important reason for me is that I want to add information about what went wrong to the status. In e.g. obj.%Save(), the returned status tells me that saving an object went wrong, and hopefully why. I want to add to this which object could not be saved, and possibly some other state that may be relevant for debugging the problem. I find this creates code that is easy to read and debug.

By the way, "If 'sc" is, to me, a lot easier on the eyes than "If $$$ISERR(sc)"...

Gertjan has no followers yet.
Gertjan has not followed anybody yet.
Global Masters badges:
Gertjan has no Global Masters badges yet.