I created this module for Golang to help me with error handling. This idea showed when a colleague of mine was thinking to pass context
from handler to service, to repository to trace the error log more verbose. I disagreed with him because I thought that’s not what context
is for. Perhaps I was wrong or he was wrong, or maybe both of us wrong because this is our first Golang project that deployed on production.
Despite our opinion about context
, we both agreed that Golang’s error handling is too verbose and bulky. It makes us read more error handling more than read the system flow itself. Then I remember when I was coding using Java/Kotlin that I always use throws
, throw
, and try-catch block
to handle any errors.
Hmm…
Why don’t I create it for Golang?
Then I create this try-catch block
module for Golang called taboo
. Because I know this thing creates polemic among Golang developer but, then I thought why don’t I give it a try?
For the design itself, I was inspired by this article but the whole implementation is all adjusted with my current needs. Instead of error
, this module is based on panic
and recover
so it is quite dangerous whenever used in the wrong condition.
Let’s take an example:
|
|
When b
is filled with zero
, it causes panic
|
|
So, we can handle it using taboo
like this:
|
|
taboo
will catch the panic
and try to recover
it and make a stack of error called taboo.Exception
to trace error more verbose. So the program ends like this:
|
|
Quite handy right?
Then, what if I want to throw or rethrow the error to the first caller?
|
|
e.Throw(message)
Will wrap the previous exception, and throw it again to the previous caller. So the printed error will be like this:
|
|
It just like try-catch block
in Java/Kotlin I think but with many flaws lol. This module is still an experiment that I myself is not going to using this module in production. Or perhaps should I?
Thank you for reading!