AllAccepted answers
Evgeny Shvarov · Oct 9, 2020

Rob, there is a logic of course behind every technology bonus of the contest. Technology bonuses are to encourage the usage of technology we invest in and approaches we consider promising and productive in development with InterSystems IRIS.

With REST-API, jdbc, native-api bonuses we support different ways to communicate with IRIS which we consider perspective and continuously improve. E.g. we don't engage the legacy CSP approach as you can see. How does mg-dbx talk to IRIS in the end?

Docker bonus is to support the "docker way" to develop and deploy solutions that we think is very promising.

ZPM bonus is to support the Package manager way to deploy applications built with ObjectScript.

Unit Testing is just helpful and I hope it's clear why we support it.

Evgeny Shvarov · Oct 9, 2020

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.

Evgeny Shvarov · Oct 7, 2020

Here is the set of updated ZPM images with ZPM 0.2.7:

intersystemsdc/iris-community:2020.3.0.221.0-zpm

intersystemsdc/iris-community:2020.2.0.204.0-zpm

intersystemsdc/irishealth-community:2020.3.0.221.0-zpm

intersystemsdc/irishealth-community:2020.2.0.204.0-zpm

And to launch IRIS do:

docker run --rm --name my-iris -d --publish 9091:1972 --publish 9092:52773 intersystemsdc/iris-community:2020.3.0.221.0-zpm

docker run --rm --name my-iris -d --publish 9091:51773 --publish 9092:52773 intersystemsdc/iris-community:2020.2.0.204.0-zpm

docker run --rm --name my-iris -d --publish 9091:1972 --publish 9092:52773 intersystemsdc/irishealth-community:2020.3.0.221.0-zpm

docker run --rm --name my-iris -d --publish 9091:51773 --publish 9092:52773 intersystemsdc/irishealth-community:2020.2.0.204.0-zpm

And for terminal do:

docker exec -it my-iris iris session IRIS

and to start the control panel:

http://localhost:9092/csp/sys/UtilHome.csp

To stop and destroy container do:

docker stop my-iris
Evgeny Shvarov · Sep 30, 2020

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.

Evgeny Shvarov · Sep 29, 2020

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?