No error in result when exception occurs

Hello,

This error message is displayed by the Composer, which (I guess) tries to display Data Shape name for returned values and fails because it is undefined. The actual service behavior is the same as in 7.4, it's just the Composer which is different. In other words, your code which uses this service shouldn't be affected. The question of whether or not it is an actual error situation deserves...

A LENGTHY TECHNICAL SIDE NOTE

TL;DR Always initialize your variables.

DISCLAIMER: This is our own hypothesis, which we've never bothered validating with PTC R&D, although we should have better done it if we were smarter.

Handling "empty" values is one of the tricky ThingWorx topics, which developers should be aware of, because it will inevitably hunt you, sooner or later. Take a look a two example services (both returning a STRING for simplicity):

// Service ExampleA, returns STRING
var result;
logger.debug(typeof result);

// Service ExampleB, returns NOTHING
logger.debug(typeof result);

Both of them produce the same log message "undefined", which is conforming to JavaScript specification. Now let's create the third service, which calls the first two:

logger.debug('A: ' + me.ExampleA());
logger.debug('B: ' + me.ExampleB());

The result is rather unexpected:

A: null
B: org.mozilla.javascript.UniqueTag@5cde3530: NOT_FOUND

There's a long explaination behind this, which goes to the fact that although from the JavaScript perspective both examples are equivalent, Rhino (the scripting engine that runs your JavaScript on the server side) handles them differently, because even though the variable "result" is not defined in the first case, it is still declared, and thus exists in the Script Context as an instance of org.mozilla.javascript.Undefined. I guess ThingWorx could have handled those two cases similarty to comply with JavaScript semantics, but it doesn't. It's not clear to me why, but I guess they had some good reason for it. Anyhow, this subtle difference has dramatic consequences.

If you want to understand that cryptic "org.mozilla.javascript.UniqueTag@5cde3530: NOT_FOUND" message, here's another explaination. In JavaScript if you don't initialize a variable, then basically "result === undefined". Unfortunately there's no direct equvalent of undefined in Java, it only supports null values, but those are already mapped to JavaScript null. So the best thing that Rhino can do in this case is to use a UniqueTag object called "NOT_FOUND" (basically a string literal), which is neither an empty string, nor null in Java. To make matters worse, once it leaves the context of the original script (e.g. when you are calling service A from service B), it stops being falsy! Again, very easy to test:

// Service ExampleA, returns STRING
if (typeof result != 'undefined') {
 logger.debug("A: There's something");
} else {
 logger.debug("A: There's nothing");
}

// Service ExampleB, returns NOTHING
var resultOfA = me.ExampleA();
if (resultOfA) {
 logger.debug("B: There's something");
} else {
 logger.debug("B: There's nothing");
}

If you execute ExampleB, you'll get this in the script log:

A: There's nothing
B: There's something

By the way, it works more intuitively if you add "var result;" to the ExampleA. Then the service outputs a proper null value, which Java wrapper around Rhino doesn't try to cast to anything else than null, and carries forward just as a null, so it propagates into ExampleB, where it is considered a falsy, outputting "B: There's nothing".

Guess what is typeof resultOfA. Indeed, it's a string, and if you try to serialize this value somehow (save it in a data table, output as XML or JSON, etc.) you'll get a legit string literal "org.mozilla......", which is obviously neither undefined, nor null nor falsy...

...Continued in the next comment...