This episode introduces logging and error handling in a Go project organized around hexagonal architecture. It outlines how logger setup, application errors, and account-related components can fit into a project. The examples are an overview; check the current documentation for any package or API before applying it to a production system.
Organize the project around clear boundaries
A project structure can make code easier to read, maintain, and extend. Hexagonal architecture separates business rules from infrastructure such as storage and from the presentation layer that handles requests and responses. The exact folder structure depends on the application; the aim is to keep dependencies and responsibilities clear.
Set up logging for each environment
The tutorial groups logging logic in a logger package and shows separate constructors for production and development configurations, named NewProduction and NewDevelopment in the example. It also covers initializing the logger, choosing log levels, changing timestamp formatting, and addressing caller information.
- Log levels: use levels such as Info, Error, and Debug to distinguish routine information from failures and diagnostic detail.
- Configuration: adjust logger settings for the environment. The episode demonstrates Viper for reading configuration values from files.
- Custom logging: a project can wrap or extend a logger when it needs consistent behavior across packages.
Keep sensitive data out of logs, and choose the level and detail that are useful for diagnosing a problem without exposing private information.
Represent and handle application errors
The episode introduces an error package and an AppError structure that carries information about an application error. Implementing Go’s error interface lets that value be handled as an error. A helper such as a “not found” constructor can make common cases more consistent.
At the request boundary, a handler can translate an application error into an appropriate response. Keeping that translation in the handler helps separate transport details from the service’s business logic.
Apply the structure to an account example
The account example is divided into a repository for data access, a service for account-related logic, and a handler for requests and responses. It outlines creating an account, retrieving account records, defining request and response shapes, and handling errors at the handler boundary.
Helper functions can reduce repeated code, but they should keep responsibilities explicit rather than hide important control flow.
Contact
For a personal-finance consultation, contact Kanngongkanngoen on LINE.
This is an introductory overview, not a complete implementation guide. Package names, APIs, and recommended logging practices can vary by version and project.