Single place to handle errors in a function

[sameerajayasoma]

Consider the following program. My aim is to provide a public API to retrieve sunrise/sunset times of a given city. The function sunriseSunsetInternal has to the logic, but it does contain many check operator usages, simply because I don't want to handle errors at every line. That would make this unreadable. I also want to give a proper error for all my API users. This is the only approach that I can think of.

Can we think of an "error handler" concept? This has been proposed in Go 2 draft as well.

import ballerina/config;
import ballerina/http;
import ballerina/io;

var appId = <@untainted>config:getAsString("OPEN_WEATHER_API_KEY");
http:Client openWeatherEp = new ("http://api.openweathermap.org/data/2.5");
http:Client sunriseSunsetEp = new ("http://api.sunrise-sunset.org");

public function sunriseSunset(string city) returns json | error {
    var result = sunriseSunsetInternal(city);
    if result is error {
        return error("RetrievingSunriseTimeFailed",
            message = string `Failed to retrieve sunrise/sunset times: ${city}`,
            cause = result
        );
    } else {
        return result;
    }
}

function sunriseSunsetInternal(string city) returns json | error {
    // Do a GET on OpenWeather API resource
    string weatherResPath = <@untainted>string `/weather?q=${city}&appid=${appId}`;
    http:Response weatherResp = check openWeatherEp->get(weatherResPath);
    json weatherPayload = check weatherResp.getJsonPayload();

    // The following line fails with the error: invalid literal for type 'tuple binding pattern'
    [float, float][longitude, latitude] = [<float>weatherPayload.coord.lon, <float>weatherPayload.coord.lat];

    // Do a GET on sunrise sunset API resource
    string sunriseResPath = <@untainted>string `/json?lat=${latitude}&lng=${longitude}`;
    http:Response sunriseResp = check sunriseSunsetEp->get(sunriseResPath);
    json sunrisePayload = check sunriseResp.getJsonPayload();

    // Create the response payload
    return {
        city: city,
        sunrise:check sunrisePayload.results.sunrise,
        sunset:check sunrisePayload.results.sunset
    };
}

[jclark]

I agree that we should find a way to handle this case better.

This is the Go 2 draft, which has lots of useful discussion.

The are a number of things to keep in mind here:

• How do we want to represent errors visually (as part of the sequence diagram)? One idea is a separate error "track".
• How do we enable easy cleanup on function return (Go does this with its defer statement)? This is issue Easier cleanup on function return #334.
• Do we need more flexible ways to trap panics? What relationship do we want between error handling and panic handling?
• What relationship do we want between check and return? If what check does with an error just return (as it is now)?
• Should we do some sort of error lifting? This is issue Generalized support for error lifting #195.
• How do we deal with transaction abort/rollback? This is part of issue Stabilize transactions support #267.

[jclark]

Unfortunately, we have used up the word handle for a type, so we cannot simple adopt Go's design, even if we wanted to.

One possibility is something like Swift's do/catch. Swift's try is similar to our check. Note that although this superficially looks like exception handling, it isn't (as the Go2 error draft explains): the flow of control is explicit.

[bruno-garcia]

I've made a comment in the lang repo but I guess this is the right place:

Ideally this would be made available to dependencies so services like sentry.io can hook and capture per/request and/or global errors.

In comparison, this is how one can extend an ASP.NET Core application with an extension method made available by Sentry's package:

https://github.com/getsentry/sentry-dotnet/blob/f4f9c908183f462b6ed6e703ae77e3e5093b3d61/samples/Sentry.Samples.AspNetCore.Mvc/Program.cs#L22

The framework offers hooks that can be used from that simple code change done by the application developer.

[jclark]

The transaction proposal change to check semantics provides a way to solve this

[mohanvive]

@jclark can you please provide more details on what block statements are going to support the on-fail clause. Below are the block statements that I could think of,

• do clause
• transaction statement
• lock

Do we need to consider below block statements as well?

• retry
• foreach
• while

What are the principles that we need to consider when deciding the block statements?

[jclark]

The principle is that it should work for any block statement that has the syntactic form

keyword keyword-dependent-syntax {
  statements
}

unless it wouldn’t make sense or would be syntactically confusing. So, for example, it should not work for if because it would get confusing with if/else. I agree it should work with the three you mention (retry, foreach, while). I would also add match (although it isn’t exactly that form).

[jclark]

Note that fail is a statement.

[jclark]

Grammar changes now in.