Bug #7252
Updated by Brett Smith about 9 years ago
Currently, the Go SDK handles SDK, and parts of Data Manager, handle 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.) In Data Manager innards, this practice makes it unnecessarily hard (impossible?) to test the relevant error functions: log.Fatal() causes the whole test suite to exit, rather than failing the current test. h3. Implementation 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. Any offending bits of Data Manager should be fixed _at least_ to the point where tests can demonstrate Data Manager's behavior when faced a network error during startup or while retrieving collections from the API server.