Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No Error Visibility #48

Open
bmeynell opened this issue Jun 21, 2017 · 3 comments
Open

No Error Visibility #48

bmeynell opened this issue Jun 21, 2017 · 3 comments

Comments

@bmeynell
Copy link

bmeynell commented Jun 21, 2017

We are interested in using this library but all API calls swallow and hide Exceptions which prevents us from knowing what error occurred.

Example: https://github.com/SiftScience/sift-php/blob/master/lib/SiftClient.php#L105-L114:

public function track($event, $properties, $opts = array()) {
    // ...
        try {
            $request = new SiftRequest(
                $path, SiftRequest::POST, $opts['timeout'], $opts['version'], array(
                    'body' => $properties,
                    'params' => $params
                ));
            return $request->send();
        } catch (Exception $e) {
            return null;
        }
}

In other words, can the try/catch within each API method be removed? Example:

public function track($event, $properties, $opts = array()) {
    $this->mergeArguments($opts, array(
        'return_score' => false,
        'return_action' => false,
        'return_workflow_status' => false,
        'abuse_types' => array(),
        'path' => NULL,
        'timeout' => $this->timeout,
        'version' => $this->version
    ));
    $this->validateArgument($event, 'event', 'string');
    $this->validateArgument($properties, 'properties', 'array');

    $path = $opts['path'];
    if (!$path) {
        $path = self::restApiUrl($opts['version']);
    }

    $properties['$api_key'] = $this->api_key;
    $properties['$type'] = $event;

    $params = array();
    if ($opts['return_score']) $params['return_score'] = 'true';
    if ($opts['return_action']) $params['return_action'] = 'true';
    if ($opts['return_workflow_status']) $params['return_workflow_status'] = 'true';
    if ($opts['abuse_types']) $params['abuse_types'] = implode(',', $opts['abuse_types']);

    $request = new SiftRequest(
        $path, SiftRequest::POST, $opts['timeout'], $opts['version'], array(
            'body' => $properties,
            'params' => $params
        ));

        return $request->send();
}

If so, then library adopters can be in charge of handling exceptions as per their unique requirements:

// User code
try {
    $client->track($event, $properties);
} catch (\Exception $e) {
    // Adopter handles here ...
}

Unfortunately, we must know when and why exceptions occur so cannot use this library for that simple reason.

@thomasschiavone
Copy link

Thanks for flagging for us. I'll get on the team's radar and I follow up as I know more.

@tiagobutzke
Copy link

I would suggest for allowing to inject (optionally) a Psr\Log\LoggerInterface into the client. Then, log the exceptions.

@ehrmann
Copy link
Contributor

ehrmann commented Mar 28, 2019

#62 will expose errors in SiftResponse. I agree that we should do more to expose those exceptions, even letting them bubble up, but looking through the code paths, I'm trying to see where they could happen under normal error conditions (network failures, invalid request data, bad json response). curl errors are reported through error codes, the json parsers return null, and SiftResponse marks errors with isOk(), so you shouldn't be seeing errors.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants