aah Error Handling
aah is versatile and seamless about handling errors. It is made for modern Web and API applications. It propagates all types of errors- Validation, Authentication, Authorization, Route Not Found and Content-Negotiation.
The propagation order is listed below -
- Controller level error handler Since v0.10
- Centralized error handler Since v0.8
- Default error handler
Benefits of aah error handling:
- Handle errors in each controller locally
- Achieve application level error handling
- Send custom HTTP code with various response types after handling errors
- Filter appropriate errors and send notification emails, slacks, etc in response.
- Log error informations and send messages to external systems such as Kibana, Prometheus, Splunk, Sentry and Airbrake.
Tip: Easy to handle errors at each level. It is also amenable to propagate further if needed.
Table of Contents
- aah Error Struct and aah Errors
- Defining Controller Level Error Handler
- Registering Centralized Error Handler
- Default Error Handler
- Reply().Error(err)
- Sample: Easy to read error stacktrace
aah Error Struct and aah Errors
Let us take a look at aah error object structure and aah errors.
aah.Error
Struct
aah errors
For framework generated errors, field Reason
holds an appropriate text from any one of these common errors.
Defining Controller Level Error Handler
Controller level error handler can be implemented using interface aah.ErrorHandler
on controller. aah propagates all controller specific errors to this handler.
Registering Centralized Error Handler
Implement error func aah.ErrorHandlerFunc
in a suitable package and register via init.go
file.
All application errors can be handled via this function- handle by Request Host
, Error Code
, etc; then it replies appropriate error(s).
Note: If it is an application panic
, then field aah.Error.Data
holds the recovered value from panic.
For Illustration Purposes
Default Error Handler
Default error handler is to handle all errors from the application and writes the reply on the wire based on Content-Type
. If reply Content-Type is not set, then Content-Type is derived from header Accept
; otherwise, it falls back to config value render.default
from aah.conf. The default error handler is capable of writing response in JSON
, XML
, HTML
and Plain Text
.
Web application has special flow for HTML error page rendering. It generally works by naming the error view file, which is the same as HTTP status code.
The default error handler looks for the error view file views/errors/<http-status-code>.<extension>
.
- If found, then it renders that file.
- See
views/errors/500.html
andviews/errors/404.html
for examples
- See
- If not found, then it uses framework default HTML error template.
Since v0.8 aah new
command generates the web application with two error files (500.html, 404.html) under views/errors
.
Reply().Error(err)
Reply().Error()
reply gets processed by Controller level, Centralized Error Handler then the reply is written on the wire.
It is highly recommended to use method Error()
for all application error responses.
Sample: Easy to read error stacktrace
And runtime.debug.strip_src_base
set to true