Aller au contenu

Gestion des erreurs

La gestion des erreurs est une partie cruciale de toute application Open API fiable et conviviale. Si vous ne capturez et ne traitez pas les différentes erreurs, vos utilisateurs peuvent rencontrer une interface utilisateur défectueuse ou être empêchés d'effectuer certaines actions essentielles.

De manière générale, différents processus de gestion des erreurs peuvent être mis en œuvre selon la couche où une erreur se produit.

  • Au niveau des données et du domaine. Dans certains cas, le backend de cTrader peut envoyer le message ProtoErrorRes en réponse à l'une de vos requêtes. Pour les opérations liées aux ordres, transactions ou positions, vous pouvez également recevoir le message ProtoOAOrderErrorEvent.
  • Au niveau du domaine et de l'application. Les utilisateurs peuvent effectuer des actions que vous n'avez pas prévues dans votre code, ce qui peut entraîner un comportement inattendu de votre application.

Les mécanismes de gestion des erreurs à ces niveaux diffèrent et sont décrits ci-dessous.

Gestion des erreurs au niveau des données et du domaine

Vous pouvez recevoir ProtoErrorRes ou ProtoOAOrderErrorEvent dans les situations suivantes (notez que la liste n'est pas exhaustive) :

  • Tentative de placer un ordre pour un symbole dont le marché est fermé.
  • Envoi d'un message incorrect ou non pris en charge.
  • Tentative de modifier un ordre en cours d'exécution.
  • Envoi d'un message après avoir perdu votre connexion au backend de cTrader.

Analyser les erreurs

Les messages ProtoErrorRes et ProtoOAOrderErrorEvent ont tous deux les champs errorCode et description qui contiennent des informations précises sur le type d'erreur survenue et sa description. Vous pouvez consulter la liste complète de tous les codes d'erreur pris en charge dans l'énumération ProtoErrorCode.

Pour vous assurer que votre application ne se bloque pas dans de tels cas, vous pouvez généralement vous abonner à des callbacks qui se déclenchent lorsque vous recevez une réponse d'erreur. La logique exacte de ces callbacks ainsi que la façon dont vous pouvez vous y abonner dépendent du client que vous utilisez pour établir une connexion et écouter le flux de messages.

Travailler avec JSON

Lorsque vous travaillez avec JSON, vous pouvez toujours réutiliser le code de ce tutoriel ; cependant, vous devrez le modifier légèrement en fonction de votre approche de sérialisation et de désérialisation et de votre client TCP et WebSocket préféré.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
private void SubscribeToErrors(IObservable<IMessage> observable)
{
    if (observable is null) throw new ArgumentNullException(nameof(observable));

    observable.ObserveOn(SynchronizationContext.Current).Subscribe(_ => { }, OnError);
    observable.OfType<ProtoErrorRes>().ObserveOn(SynchronizationContext.Current).Subscribe(OnErrorRes);

    observable.OfType<ProtoOAOrderErrorEvent>().ObserveOn(SynchronizationContext.Current).Subscribe(OnOrderErrorRes);
}

private void OnOrderErrorRes(ProtoOAErrorRes error)
{
    Console.WriteLine($"Error: Error {error.ErrorCode}; {error.Description}");
}

private void OnErrorRes(ProtoErrorRes error)
{
    Console.WriteLine($"Error: Error {error.ErrorCode}; {error.Description}");
}

Lorsque vous utilisez la bibliothèque twisted pour gérer les opérations asynchrones, vous devez vous abonner à un callback d'erreur chaque fois que vous envoyez un nouveau message, comme illustré dans l'exemple ci-dessous pour ProtoOAVersionReq.

1
2
3
4
5
6
7
8
def sendProtoOAVersionReq(clientMsgId = None):
    request = ProtoOAVersionReq()
    deferred = client.send(request, clientMsgId = clientMsgId)
    deferred.addErrback(onError)

def onError(failure):
    print("Message Error: ", failure)
    reactor.callLater(3, callable=executeUserCommand)

Gestion des erreurs au niveau du domaine et de l'application

La façon dont vous gérez les erreurs au niveau du domaine et de l'application dépend du langage de programmation choisi, du framework d'interface utilisateur et des cas d'utilisation que vous implémentez, ce qui rend difficile la fourniture d'extraits de code et de solutions spécifiques.

Cependant, les recommandations suivantes peuvent s'avérer utiles, quel que soit votre choix d'intégration avec cTrader Open API.

  • Implémentez toujours un état d'erreur dédié pour les principaux éléments de l'interface utilisateur. Cela empêchera votre application de se bloquer complètement et permettra de fonctionner dans un état semi-dégradé.
  • Mettez en place un mécanisme de journalisation sécurisé et fiable qui enregistrera les erreurs dans un emplacement approprié (par exemple, le stockage local). En cas d'erreurs répétées, la journalisation devrait simplifier l'identification et la résolution de leur cause.
  • Créez un mécanisme permettant aux utilisateurs de vous informer des erreurs. Cela peut être aussi simple que de fournir vos coordonnées dans l'application ou aussi complexe que d'ajouter un service de soumission automatique de commentaires qui se déclenche lors de nouvelles erreurs.
  • Assurez-vous que toutes les ressources utilisées lorsque des erreurs se produisent sont correctement nettoyées. Bien que la plupart des langages offrent des services de ramasse-miettes, vous pouvez souhaiter spécifier une logique personnalisée de libération des ressources.