Errors and Warnings

Public operations can throw exceptions, for example when checking a license or changing settings while the handler is running. The handler also reports issues through OnixS::CME::MDH::HandlerListener::onWarning and OnixS::CME::MDH::HandlerListener::onError. These callbacks can run during a public call or later during feed processing; a callback does not necessarily imply asynchronous execution.

Register the listener before starting:

 
struct : public HandlerListener
{
     void onWarning(Handler&, const WarningArgs& warning)
     {
         std::cout << "Warning:" << warning.description() << std::endl;
     }
 
    void onError(Handler&, const ErrorArgs& error)
    {
        std::cout << "Error:" << error.description() << std::endl;
    }
}
listener;
 
Handler handler;
handler.settings().listeners().handler(&listener);
 

Observing startup

OnixS::CME::MDH::Handler::start returns void. Returning without an exception does not establish that startup succeeded or that market data is ready. Startup follows these paths:

Condition	Application observation
License check fails	start() throws from license validation; this path does not invoke onError or onStopped.
Preparation fails, for example because connectivity settings are invalid	On the calling thread, onError reports OnixS::CME::MDH::Issue::OperationFailure. The handler then releases feeds, enters the stopped state and invokes onStopped, all before start() returns.
Preparation succeeds	onStarted runs on the calling thread before the handler connects its incremental feeds. It does not confirm connectivity or recovery.
A feed connection fails	onError reports OnixS::CME::MDH::Issue::ConnectionFailure. The connection path handles the failure internally, so it need not throw from start() or invoke onStopped.

An exception escaping the remaining startup work is handled like a preparation failure, so an application can receive onStarted followed by OperationFailure and onStopped. Feed events and warnings can also occur during startup. Exceptions from listener callbacks are handled separately; see Exceptions.

The following observer records lifecycle changes and counts startup and connection failures in application-owned, synchronized state. The call site also catches exceptions:

enum class ProcessingLifecycle { Stopped, Started };
enum class StartCallResult { Returned, Threw };
 
struct StartupObserver : HandlerListener
{
    std::atomic<ProcessingLifecycle> lifecycle{ProcessingLifecycle::Stopped};
    std::atomic<unsigned> operationFailures{0};
    std::atomic<unsigned> connectionFailures{0};
 
    void onStarted(Handler&) override
    {
        lifecycle.store(ProcessingLifecycle::Started);
    }
 
    void onStopped(Handler&) override
    {
        lifecycle.store(ProcessingLifecycle::Stopped);
    }
 
    void onError(Handler&, const ErrorArgs& error) override
    {
        if (error.id() == Issue::OperationFailure)
            ++operationFailures;
 
        if (error.id() == Issue::ConnectionFailure)
            ++connectionFailures;
    }
};
 
// Configure license, feeds and session first; keep observer alive with the Handler.
StartCallResult observeStart(Handler& handler, StartupObserver& observer)
{
    handler.settings().listeners().handler(&observer);
 
    try
    {
        handler.start();
        // Inspect observer and subsequent events; Returned is not a readiness result.
        return StartCallResult::Returned;
    }
    catch (const std::exception& error)
    {
        std::cerr << error.what() << std::endl;
        return StartCallResult::Threw;
    }
}

Initialize the observer before each start attempt, while no callbacks are running. Use the recorded issues to diagnose failures and arrange any stop/retry on the application's control thread, after the current callback and lifecycle call return. See Operations from callbacks.

Track recovery outcomes and real-time processing separately from startup. See Processing Phases and Data Readiness and Interpreting a book update for the applicable events and their limits.

Repeated start and stop calls

After the license check, start() begins a new attempt only if the handler is stopped; otherwise it does not start another session or raise another onStarted. The license check still runs on each call. The deprecated overload taking session settings can additionally throw when trying to change settings on a running handler.

OnixS::CME::MDH::Handler::stop performs shutdown only for a processing handler. Calling it on an already stopped handler does not raise another onStopped. On ordinary shutdown, feed disconnection notifications precede onStopped; the handler becomes configurable after that callback returns. Serialize lifecycle calls in the application; repeated calls are not a way to cancel an in-progress start or shutdown.

See also

Event listeners