Rob! Correct me if I'm wrong, QEWD-conduit uses InterSystems node.js driver to talk to IRIS, right?  And QEWD-conduit gets Native API bonus for this.

The REST API description requests the usage of InterSystems REST API to have IRIS be a REST API server.

As for the iris docker bonus - we didn't manage yet to run QEWD-conduit with any iris-docker image available according to the QEWD  instruction.

Thanks for the reply, Alexey.

my topic is an attempt to find the value in %Status why people use it even for their own methods.

IMHO it steals the option of return values from methods and code looks dirty with “mandatory” $$$TOE or $$$ISERR for every call of the method with %Status

AFAIK Try/catch indeed slows a bit the execution (@Dan.Pasco is it true?)

And try/catch shouldn’t be presented in every method - it could be somewhere on top and in the places where you need to catch errors.

I like your answer but for better understanding it deserves a sample code to see how do you manage error scenarios.

we really lack of good templates for beginners on how to better handle errors in serious project.

Thanks for the insights, @Herman Slagman!

$ZT + Label is better than try/catch

%Status is better than try/catch too.

why %Status is better than throw ("something went wrong") approach?

But, how to do you track errors of your solutions happen on a customer side? There is an elegant way to manage this with try/catch:

catch e {

 do e.log() // store the error and stack in Application Errors

// handle error

} 

How could you manage this with %Status and $ZT approach?

Thanks, Jon!

Why try-catch doesn't work well without finally? I think finally is only for the cases when you need to free resources taken, isn't it?

Thanks for the answer, Gertjan!

May I ask you, why don't you like try/catch? Is it slow?

Imho it has all the error and stack information, what's wrong with try/catch?

I think if the method should return something else, it should return not %Status but the value.

Thanks, Steve!

Thanks, Ben!

This is another good topic for discussion on should the test code be included in the production