{"id":17956017,"url":"https://github.com/ifraixedes/go-errors","last_synced_at":"2025-06-24T06:33:15.150Z","repository":{"id":57515664,"uuid":"162173420","full_name":"ifraixedes/go-errors","owner":"ifraixedes","description":"Go errors with error codes through a simple and small API","archived":false,"fork":false,"pushed_at":"2019-02-06T19:49:13.000Z","size":100,"stargazers_count":0,"open_issues_count":2,"forks_count":0,"subscribers_count":2,"default_branch":"master","last_synced_at":"2025-03-09T12:44:48.843Z","etag":null,"topics":["error-codes","errors","golang"],"latest_commit_sha":null,"homepage":null,"language":"Go","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/ifraixedes.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2018-12-17T18:29:07.000Z","updated_at":"2019-01-24T19:55:41.000Z","dependencies_parsed_at":"2022-08-30T04:21:13.452Z","dependency_job_id":null,"html_url":"https://github.com/ifraixedes/go-errors","commit_stats":null,"previous_names":[],"tags_count":2,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ifraixedes%2Fgo-errors","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ifraixedes%2Fgo-errors/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ifraixedes%2Fgo-errors/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ifraixedes%2Fgo-errors/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/ifraixedes","download_url":"https://codeload.github.com/ifraixedes/go-errors/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":247043352,"owners_count":20874087,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["error-codes","errors","golang"],"created_at":"2024-10-29T10:34:07.810Z","updated_at":"2025-04-03T17:18:16.723Z","avatar_url":"https://github.com/ifraixedes.png","language":"Go","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Go Errors\n\n[![Coverage Status](https://coveralls.io/repos/github/ifraixedes/go-errors/badge.svg?branch=master)](https://coveralls.io/github/ifraixedes/go-errors?branch=master)\n[![Build Status](https://travis-ci.com/ifraixedes/go-errors.svg?branch=master)](https://travis-ci.com/ifraixedes/go-errors)\n[![Go Report Card](https://goreportcard.com/badge/go.fraixed.es/errors)](https://goreportcard.com/report/go.fraixed.es/errors)\n[![GoDoc](https://godoc.org/go.fraixed.es/errors?status.svg)](https://godoc.org/go.fraixed.es/errors)\n\nThis package provides a simple API for creating and handling errors which are identified by codes.\n\nThe correct import path of this package is `go.fraixed.es/errors`.\n\n## Rationale\n\nMany times, a library, service, or any other kind of implementation needs to\ndeal with third party packages and it may need to identify errors for:\n\n1. Perform some operation before returning it to the caller, for example doing\nsome kind of rollback operations.\n2. Localize the error.\n\nMeanwhile those 2 needs could be implemented with error values (defining them\nas global variables of the package) or specific types, both of them aren't ideal\nbecause:\n\n1. Package variables values cannot be modified on each error instance, so they\ncannot to be endowed with specific information which is useful for the\ndevelopers and operations teams for identifying the source of the problem.\n2. Package variables aren't immutable, so their values, although unlikely, could\nbe erroneous overridden.\n3. Specific types don't have the 2 previous problems, however when a considerable\nlist of different errors is needed, quite a few boilerplate is required for\ncreating them and the package documentation gets polluted.\n4. Specific types must implement the same behavior over and over or use a base\ntype which must be embedded in all the types to have the same logic. This could\nbe fine in single package, but when you want to have the same mechanism on a\nbunch of packages (think in medium/large implementations done by any company\nwhose code base is written in Go) is less than desirable to spread between\nteams.\n5. When using any of them and the errors are transmitted over the wire (this\nproblem arises when the dependency is a remote service), then the client must\nidentify those errors in order to reconstruct the error to use the same value\n(when using package variables) or type (when using specific types) for allowing\nthe caller to be able to identify the error.\n\nThe 2 mentioned issues can be solved by errors which are identified by codes and\nwithout the need of using package variables nor specific error types, just using\na minimal and simple public API exposed by this package. Nonetheless this\npackage doesn't attempt to fit to all the use cases, it fits to several of the\nuses cases which were found in my experience, but they are not all. Hence,\nbefore using it, assess  if it can bring the mentioned benefits to your\nimplementation (for example a minimal library may have enough just returning\nstandard errors or using a couple of package variables error values variables or\nspecific types).\n\n## Errors information\n\nErrors are for users, but they must be useful for operations, too. In order to\nachieve both, the error type of this package is endowed with several information.\n\n1. A code and a static message. Both information is useful for users and\noperations, because each code should be quite specific and self descriptive for\nproviding a synthesized information about the error which has happened. Having\na specific error code is also good to have each error properly documented, so it\ncan provide more detailed information about the error when its synthesized\ninformation isn't enough.\n2. An unique ID. Each error instance has an unique ID. For users, it's useful\nbecause they could report it to the support team, a part of the code. Such ID\ncould be helpful to provide a customized feedback/response when needed and for\nthe operations team, could use the ID to correlate errors, when they are\nregistered/tracked in different operational systems or, for any reason, in the\nsame one several times.\n3. Metadata. Despite that the code, and its associated message, should be\nprecise, the operations team needs more information about what happened when the\nerror has happened in some circumstances which aren't clear, for example the\ninput parameter values, variable values, etc. Developers should have a way to\nprovide such important context information when creating the errors and that's\nwhat, in this package, is called metadata.\n4. The call stack. Call stacks are ugly, but they provide the trace where the\nerror was originated and such information is very useful for the operations team\nand maintainers, when the error has happened in unclear circumstances.\n5. Original error. The most of the times, third party packages are used and,\nobviously, those package don't probably use errors created by this package,\nhence they don't have all the information, or a lest in the same way. Your\nimplementation has committed to return error with codes, but the original error\nmust be preserved because it may have additional information which may be useful\nfor the operations team and maintainers.\n\nIn summary, from the point of view of users, the error should be precise and\nconcise, without having any useless information and avoiding to leak important\ninformation about the system; on the other hand, the operations team and\nmaintainers need much more information about the errors in order of being able\nto understand the cause of the error.\n\n## Errors are standard errors\n\nThis package doesn't intentionally export the error type, because:\n\n1. Functions' signatures, which return errors, should always return a standard\nerror.\n2. Type assertion for finding out errors information is less than ideal in\ncomparison on having an API.\n\nHence, this package export some functions to get information about the error,\nhowever it only intentionally allows to get a part of it, because the\ninformation destined for operations is only thought to be exposed through\nsystems for such purpose, for example logging.\n\n\n## License\n\nMIT, read [the license file](LICENSE) for more information.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fifraixedes%2Fgo-errors","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fifraixedes%2Fgo-errors","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fifraixedes%2Fgo-errors/lists"}