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).

HTTP response status codes - HTTP | MDN

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).