When writing server-side code, developers need a way to react to errors happening on network connections. These errors may occur due to malicious activities, like malicious clients establishing network connections without sending any data. Malicious clients can also send rogue data, making the Cute server drop the network connection. Developers need a way to take action whenever such activities occur.
The Cute server allows an instance of an error handler to be registered. The server reports all errors from all workers to this instance. The error handler does not need to serialize access to it as the Cute Server does this serialization before reporting errors to the registered handler.
The error handler must inherit from the IErrorHandler class, and an instance of this class is registered using the setErrorHandler function.
Note that as remote objects are compiled into a shared library and loaded by the server, the best way to call setErrorHandler is by using function attributes, which GCC and Clang support, as shown below:
// function to run when library loads __attribute__((constructor)) static void initialize_remote_objects_lib() { // MyErrorHandler is a class that inherits IErrorHandler Cute::setErrorHandler(new MyErrorHandler); }
One important thing that users should note involves the errors that Cute reports whenever the connection drops. If the connection drops on HTTP-based interaction or if it drops before the server creates the first remote object on the WebSocket connection, then QAbstractSocket::RemoteHostClosedError is sent in the error info to the registered error handler. Otherwise, on remote object-based interaction, if the server creates at least one remote object before the connection drops, then the Cute::ConnectionError::ConnectionDropped signal is emitted instead.