Errors such as “divide by zero” are detected by the environment (OS) and handled by Lumigo. On the other hand, an error in business logic, for example, trying to delete a customer who doesn’t exist, cannot be detected by the environment but only by the application. Errors such as these are known as “programmatic errors”.

Lumigo enables you to harness its full error analyzing capabilities for programmatic errors by adding just a few lines of code to your Lambda handler. You can log programmatic errors, send Alerts , and view them on the Issues page.

Viewing Programmatic Errors on the Issues Page

In the first image below, you can see some programmatic errors (marked with a yellow label) appear as viable Issue Types in the Issues list.

The next image shows how the details of a programmatic error are broken out in a graph view of a transaction.

Configuring a Generic Programmatic Error

Programmatic Errors can be configured from anywhere within your Lambda handler’s code. Choose the appropriate snippet below:

print("[LUMIGO_LOG] <YOUR MESSAGE>")

console.log("[LUMIGO_LOG] <YOUR_MESSAGE>");

System.out.println("[LUMIGO_LOG] <YOUR_MESSAGE>");

Configuring a Custom Programmatic Error

You can add your own custom types of errors, using one of the two options listed below:

import lumigo_tracer
lumigo_tracer.error("a description of the error", "My Custom Type")

const lumigo = require('@lumigo/tracer');
lumigo.error("a description of the error", { type: "My Custom Type" });

or

error = {
    'message': 'a description of the error',
    'type': 'My Custom Type'}
print("[LUMIGO_LOG]", json.dumps(error))

let error = {
    'message': 'a description of the error',
    'type': 'My Custom Type'
};
console.log(`[LUMIGO_LOG] ${JSON.stringify(error)}`);

Examples

Let's say your system implements some user notification service, which uses a 3rd party for SMS delivery. This external service has its own programming model and its own set of possible reported errors, which are returned within the HTTP response to the service.

• If the service behaves in some way that is compliant with its programming model (i.e, does not return an error) but that is unexpected or has a negative impact on your system - you can report this to Lumigo from your code. For example, if Twilio SMS API discards outgoing SMS requests that contain an empty message body (but does not return an error indication) - you can report Lumigo on this event as a programmatic error.

• If a service returns multiple error messages for different cases. Your application and your team may care more about some of these errors and less about others, so looking at all of the errors through a single lens (for example, as generic 4xx or "client errors") could be very inefficient. You can use a custom programmatic error type for each of the cases, and then assign, track and analyze each of them individually without losing the context of that error.

Let's take this example and show how Programmatic Errors can be used. Consider this as a 400 response returned from Twilio:

{
    "code": 14108,
    "message": "Invalid Phone Number",
    "more_info": "https://www.twilio.com/docs/errors/14108",
    "status": 400
}

Then our code could report Lumigo Programmatic Errors in the following way:

.
.
.
response = twilio_client.messages.create(body=sms.message,
        from_=sms.sender, to=sms.recepient)

if response.status == 400:
    if response.code == 14108:
        lumigo.error(response.message, 'Twilio: Invalid Phone Number')
    elif response.code == 32103:
        lumigo.error(response.message, 'Twilio: Empty SMS Body')
    .
    .
    .
    else:
        lumigo.error(response.message, 'Twilio: Client Error')
.
.
.

Resulting in multiple unique issues: