Error handling refers to the response and recovery procedures from error conditions present in a software application. It is the process comprised of anticipation, detection and resolution of application errors, programming errors or communication errors.
There does not seem to be any separation between the error code and error text in a %Status object. For custom errors, I simply want to display the message and not Error #5001: Some error text.
ObjectScript has at least three ways of handling errors (status codes, exceptions, SQLCODE, etc.). Most of the system code uses statuses but exceptions are easier to handle for a number of reasons. Working with legacy code you spend some time translating between the different techniques. I use these snippets a lot for reference. Hopefully they're useful to others as well.
In a Business Process (BPL) I noticed that if I 'm using a "scope" to handle errors then inside the "scope" when a "call" is used, the "request" and "response" action (i.e set for callrequest.prop = request.prop & response.prop = callrespones.prop does NOT work ! The result is that the values of those properties in the callrequest are nulls (I do see the properties names in the content of the callrequest message)
Lets imagine that there's a process that locks an entry of a gived domain, in my example the ID 2 of the table User.tApplications and using an exclusive lock. Additionally the error handling is managed by a $ETrap routine wich will look for error data in order to log it
I used the operation : EnsLib.EMail.AlertOperation to send mail to handle error. However, I want to get more information about the error (session ID message, the date, the namespace... etc).
what is the best way to do it?
I tried to add informations in OnAlertRequest method as below but I need to change mail operation from all namespaces...
Hello again! Welcome to the Part 2 - Handling payloads!
If you're new to this series, I'd recommend you to check out the Part 1 - Core concepts. You'll need a basic understanding about how Frontier works before continuing with the Part 2.
Caché Version String: Cache for UNIX (Red Hat Enterprise Linux for x86-64) 2016.2.1
We have a mirrored Ensemble system (110, backup and 210, primary). At one time (14:00) there is a disruption in the production. The messages are not being processed.
I am trying to apply a temporary time-limited key for our organization to a Cache Server that I built out a few weeks ago for testing purposes. When I navigate in the portal to activate a new license key, I get this "ERROR #8610: License keys are not accepted on a Single User (SU) platform."
I have an XML I am sending to an operation from a BPL. This is a query for Patient information from Epic using a web service. I created the operation using the add-in in Studio. I setup the BPL to do a Call and send whatever data I receive from the client. I get a response back from Epic with a list of matching Patients. In the BPL I am trying to use the Response Builder to pass the response ID, name, DOB, etc. to matching context items to then pass to the client as a response. I get the following error within the call:
How can I prevent large number truncation when using the DynamicObject and DynamicArray classes to create JSON in objectscript and then parsing the result in javascript. Are there any global settings that configure the output when using these classes?
I am looking at converting to the new DynamicObject and DynamicArray classes to build JSON. Our current (homegrown) JSON library forces string representation of numbers too long because of errors we were seeing with long numbers being truncated on the client, I am hoping to accomplish the same with the new classes.
A beginner’s guide to Exception Handling in RESTful web services. The article gives an example how the various error conditions during processing a service request can be handled.
We expect our client – server communication working in a flawless operational condition, running error free software. But we are prepared to handle exceptions. Are we? So far in the examples of the previous sessions were not. We did not care about exceptions. The result? In any error incident it took ages to figure out what the problem is and more importantly how to fix it.
By update