none
Incohérence de type dans la propriété Interval de System.Timers.Timer RRS feed

  • Question

  • Bonjour,

    Je travaille actuellement sur un logiciel pour lequel nous avons besoin d'utiliser des Timer afin de gérer efficacement le déclenchement automatique de certaines tâches (petite précision, je travaille avec .Net Framework 3.5). Notre logiciel est actuellement en "pré-prod" chez certains clients, et depuis quelques jours je dois jongler avec une erreur assez spéciale lors de l'appel de la fonction Start() d'un timer de type System.Timers.Timer :

     

    ArgumentOutOfRangeException : Le nombre doit être soit non négatif et inférieur ou égal à Int32.MaxValue, soit -1. Nom du paramètre : dueTime

     

    Il s'avère qu'après mainte vérifications, la valeur insérée dans la propriété Interval du Timer est bel et bien supérieur à 0. Cependant, cette dernière n'est pas inférieure à int.MaxValue. int.MaxValue vaut 2147483647 alors que ma valeur vaut 2592000000 (ce qui représente 31 jours en millisecondes).

    Jusque là, rien d'alarmant, je sais d'où provient mon erreur, et je suppose connaître une solution pour contourner mon problème.

    Seulement voilà ...

    Je me demande bien pourquoi le Timer a été conçu pour prendre en paramètre un Interval de type double, alors qu'en interne (merci Reflector), lorsqu'il calcul son 'dueTime', il effectue brutalement un cast de l'Interval en type int.

    Le problème vient de cette conversion chaotique. En effet, la valeur du MSB du paramètre de type int passé à l'élément System.Thread.Timer, qu'utilise le System.Timers.Timer, fait croire que le dueTime vaut -1702967296, et qu'il est donc inférieur à -1. Dans ce cas, une exception est générée, et pour ma part je ne peux pas utiliser mon Timer pour qu'il se déclenche 31 jours plus tard. Je pense que l'utilisation du type uint (ou du type double de la propriété Interval) aurait été beaucoup plus appréciable.

    J'admet manquer de sommeil en ce moment, mais quelqu'un a-t-il une explication ? (après tout, il se peut que ce cast est un motif réel et sérieux qui m'échappe complètement)

    Est-ce qu'il est prévu que ce "problème" soit "résolu" dans la prochaine version du FrameWork ? (j'ai toujours préféré fournir un code sans bidouille ... je trouve personnellement que "ça fait plus sérieux")

    Par avance merci pour vos lectures et/ou réponses.

    Cordialement,

    Emilien


    XR
    jeudi 10 mars 2011 16:14

Réponses

Toutes les réponses