Have you ever face a situation where an error is occurred on your code, but not quite sure on which file it is exactly happening? Then me too
In real-life app development, where our app is most likely coded in a ton of files, finding the root cause of an error is quite time-consuming.
Usually during the development process, sometimes we dispatched a client HTTP call for testing purposes to a _bugged _endpoint on our web service. We expecting an error on the response, and there it is, a logical error occurred. We need to fix it, fast! A.S.A.P!
Naturally what we developer will do in the first place is gathering the error messages from the client HTTP call response, from the backend error log, from other places. And then we will proceed with doing the root cause analysis, and one of it is predicting the possible location of the file, function, line of the code where the error is occurred based on the clue from error messages. If the clue is clear enough we might able to get the line of code in no time. Otherwise ….
- Check the route handler to get the controller class
- And then go to the controller code, to check the action method
- And then go to the model codes, go to service codes
- And then go to database package code
- …. then the database utility code, then the other utility code, …
It might take some time, but it works right? It will always work. Especially when our app’s logging mechanism is good, then we might need lesser time to find the exact line of code that causes the problem.
Is it really enough? probably. But I guess, there is always room for improvement right? 😁
#programming #go #golang
