github.com/qioalice/ekago/v3@v3.3.2-0.20221202205325-5c262d586ee4/ekaerr/README.md (about) 1  2 3 # `[ekaerr]` An error management you deserve 4 5 ```go 6 import "github.com/qioalice/ekago/ekaerr" 7 ``` 8 9 ## What? 10 11 `ekaerr` is an error generating and managing package which is extremely linked with [`ekalog`: _intelligence logging package_](../ekalog/). 12 13 Now you can: 14 - Generate stacktrace based error objects with a possibility to adding fields (arguments), additional messages to **each** stackframe; 15 - Add _Public error message_ which you can use later for example as a part of API response; 16 - Have an unique `error_id` for each error object. UUID to be more precision; 17 - Divide errors by _error classes_, use prepared built-in error classes like `DataUnavailable`, `IllegalArgument`, and others or declare your own. 18 19 20 ## Why? 21 22 Golang has very primitive error management by default. It's just error interface with `Error() string` method. All you can do w/o extern libraries is create a simple error message with some text, nothing more: `errors.New(...)` or `fmt.Errorf(...)`. 23 24 What if you want stacktrace? LetterMessage's fields like IP addr, user's ID? Or add auxiliary messages for each stacktrace's frame that could be describe what happened in details? 25 26 Imagine you define a func, that may be failed: 27 ```go 28 func foo1() error { ... } 29 ``` 30 What do you do if func has been completed with `err != nil` ? Log it, i guess. But what if `foo1` has been called inside `foo2` that has another functions calls and also returns an `error` object? Like 31 ```go 32 func foo2(arg1, arg2 any) error { 33 // You has code here 34 if err := foo1(); err != nil { 35 // Log? Like "foo2 has been failed because of foo1"? 36 // But what's about arguments 'arg1', 'arg2'? 37 // Are they important? 38 } 39 // And here you also has a code 40 } 41 ``` 42 So, it's already complicated, isn't? What if you have `foo3`, `foo4`, `foo5`? Nested? Or instead of code placeholders in the example above? 43 44 Moreover. 45 Ok, let's pretend you logged it somehow. What's about API? Will you just return HTTP 500 code to your user if it's web server? Or how do you make it clear for user what's happened when you need 46 - Log as more info as you can to perfectly understand what happens and fix it easiest way 47 - Tell to the user only common regular info, nothing more, especially your runtime private data 48 49 at the same time? 50 51 And now imagine how it would be great if: 52 - You accumulate as more error related data as you want and all that as one error object 53 - You add your custom arguments, messages 54 - You log it 55 - You send its unique ID to the user's (no more unclear HTTP 500 or _"an error has been occurred"_) 56 - User can write to your support about error using unique ID 57 - Support can find all related error's info by it's ID and send it to your tech specialists 58 - Tech specialists (of course it's you) do fixes 59 60 61 ## How? 62 63 < in development > 64 65 ----- 66 67 Inspired by [joomcode/errorx](https://github.com/joomcode/errorx).