Style Development Log 1 : Exception Handling
Join our discord community https://discord.gg/bPcscvBM for news.
I will share the developments related to the style backend framework, which I have announced in the article, in a series. If you have no idea about
style or don't understand the components in the examples below, please take a look at the main
article.
You can subscribe to the medium account by e-mail to follow the developments. I will not
add an article on a topic other than this series and style and all is free-read. This series can be thought of as a
developer blog. For this reason, I will share developments are added. The subject context expected
from a documentation should not be expected from this series.
As it is known, a backend can receive many unexpected requests while in runtime. These unexpected
requests and transactions are handled, and the error message is sent to the client. These may be
developer-related(e.g. wrong type cast), or they may be Exceptions(Unauthorized request) that are expected to occur at runtime.
First, in order to minimize unexpected errors in style, errors originating from the component
tree are taken during the first run of the server. The program will stop because these errors are
not handled.
At runtime, all exceptions from requests are handled, and the server is not stopped. Errors are not handled because avid_catches_without_on_clauses.
The Wrapper
topic in my main article are important to explain this topic.
Wrap for Exception
With Style, ExceptionWrapper<Type>
you can define an endpoint for all exceptions by type that occur below the wrapper.
The wrapper created for a super class is used if it is not wrapped with the exact type of exception occurring in the context of the endpoint. If it is not present, it will be handled with the “Exception” endpoint wrapped by default.
This example all exceptions handled by MyExEnd
endpoint.
ExceptionWrapper<Exception>(
child: Route(
"exception",
root: Throw(Exception("always throw"))
),
exceptionEndpoint: MyExEnd()
)
Hierarchy
Wrapping exceptions are overwritten when rewrapped in subcomponents.
There are 4 separate layers of exceptions. (most inclusive on top)
- Exception
- StyleException — Other Exceptions
- ExceptionGroup (StyleException Implementations : Client Error, Server Error)
- ExactType (Exception Groups implementations)
The following sequence is followed when getting for exception endpoints in context.
StyleException
StyleException
is an exception implementation. This exception carries information on it, such as statusCode, where the exception occurred, what request it was processing, and client information etc.
ClientError — Server Error
They are exceptions with 4**/5** status codes. All exceptions in the link below have been implemented.
E.g. there is NotFoundException
(404).
Examples
All exceptions as a last resort .
ExceptionWrapper<Exception>(
child: ..,
exceptionEndpoint: MyExceptionEndpoint()),
Handle All StyleException
If exact type or intermediate(client-server error) type is not wrapped.
ExceptionWrapper<StyleException>(
child: ..,
exceptionEndpoint: MyExceptionEndpoint()),
Handle all ClientError
if not exact type wrapped.
ExceptionWrapper<ClientError>(
child: ..,
exceptionEndpoint: MyExceptionEndpoint()),
Handle BadRequests
.
ExceptionWrapper<BadRequest>(
child: ..,
exceptionEndpoint: MyExceptionEndpoint()),
Handle FormatException
.
ExceptionWrapper<FormatException>(
child: ..,
exceptionEndpoint: MyExceptionEndpoint()),
More than one definition
ExceptionWrapper.fromMap(
map: {
InternalServerError : My500Endpoint(),
MethodNotAllowedException : My405Endpoint()
},
child: ..,),
Server Defaults
Same as ExceptionWrapper.fromMap
Server(
defaultExceptionEndpoints: {
InternalServerError : My500Endpoint(),
MethodNotAllowedException : My405Endpoint()
},
children: []
);
Endpoint
/// TODO: Document
class MyStyleExEndpoint extends ExceptionEndpoint<StyleException> {
MyStyleExEndpoint() : super();
@override
FutureOr<Response> onError(
Message message, StyleException exception, StackTrace stackTrace) {
return (message as Request).createResponse({
"err": "client_error_received",
"type": "${exception.runtimeType}",
"sup": "${exception.superType}",
"st": stackTrace.toString()
});
}
}
Message
is may Request
or Response
. Because exception may occurred after response created. (Eg. occurred in ResponseSchemaGate
).