Project

General

Profile

Actions

Bug #7252

closed

[SDKs] Return errors instead of calling log.Fatal in code that needs to be tested

Added by Tom Clegg over 9 years ago. Updated about 9 years ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Radhika Chippada
Category:
Keep
Target version:
Start date:
09/10/2015
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
Story points:
1.0

Description

Currently, the Go SDK handles some runtime errors by calling log.Fatal(). In an SDK, this practice is unacceptable: the caller, not the library, should decide whether a given error should cause the entire process to exit abruptly. (The same goes for logs -- the application should be able to inspect and suppress logs if it wants to -- but while ugly, this is at least not fatal.)

The Go SDK should never exit -- via log.Fatal or anything else -- except at startup due to an error in the SDK's own code (e.g., it is OK to call regexp.MustCompile on a constant string). If it is possible for a function to encounter an error it can't handle, it should include an error in its return values. The caller must decide whether the error is fatal.


Subtasks 1 (0 open1 closed)

Task #7787: Review branch: 7252-go-sdk-errorsResolvedRadhika Chippada09/10/2015

Actions

Related issues 1 (0 open1 closed)

Related to Arvados - Story #6260: [Keep] Integration test between data manager, API and keepstore.ResolvedRadhika Chippada08/19/2015

Actions
Actions

Also available in: Atom PDF