aah Error Handling
aah error handling is made for modern Web and API application. It propagates all the errors [Validation Error, Authentication, Authorization, Route Not Found, Content-Negotiation, etc.] in the below mentioned order. You have complete control over each error happening within your application and how it should be treated, etc.
The propagation order is -
- Controller level error handler Since v0.10
- Centralized error handler Since v0.8
- Default error handler
Benefits of aah flexible error handling, you could -
- Handle error at each controller locally
- Handle error at application level
- Handle error then send custom HTTP code with various response types.
- Filter/process appropriate error then send notification email, slack, etc.
- Log error information; also send it to external systems. For e.g: Kibana, Prometheus, Splunk, Sentry, Airbrake, etc.
Seamlessly integrated across within framework and its flow.
Tip: Possible to handle error at each level, also possible to propagate to further above if needed.
Table of Contents
- aah Error Struct and aah Errors
- Defining Controller Level Error Handler
- Registering Your Centralized Error Handler
- Default Error Handler
- Reply().Error(err)
- Sample: Easy to read error stacktrace
aah Error Struct and aah Errors
Let’s take look at aah error object structure and aah errors.
aah.Error
Struct
For framework generated errors, field Reason
would be from these errors -
Defining Controller Level Error Handler
It’s very easy, just implement interface aah.ErrorHandler
into your controller. aah would propagate all the errors happening within that controller to this handler.
Registering Your Centralized Error Handler
Just implement this error func aah.ErrorHandlerFunc
in an appropriate package and register via init.go
file.
Then you could handle all application errors via this function. Such as handle by Request Host
, Error Code
, etc. Then reply appropriate error response.
Note: If its was an application panic
then field aah.Error.Data
holds the recovered value from panic.
Just for an example
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 fallbacks to config value render.default
from aah.conf). It is capable of writing response in JSON
, XML
, HTML
and Plain Text
.
Web application has special flow for HTML error page rendering, it typically works by naming your error view file the same as HTTP status code. Default error handler:
- First it does lookup under
views/errors/<http-status-code>.<extension>
if found then it render that file.- For example:
views/errors/500.html
,views/errors/404.html
- For example:
- Otherwise 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 is gets processed by Controller level, Centralized Error Handler then your reply is written on the wire.
It is recommended to use method Error()
for all the application error responses.
Sample: Easy to read error stacktrace
And runtime.debug.strip_src_base
set to true