Sur quelle (s) ligne (s) ce code pourrait-il renvoyer une exception "L'index était en dehors des limites du tableau"?

Question

Un peu de contexte sur cette erreur: Le client recevant ce message d'erreur dans son fichier journal et son support n'a pas été en mesure de le reproduire pour le moment. Donc, j'examine le code en essayant de déterminer ce qui pourrait se passer. Je l'ai réduit à cette section du code en examinant leur fichier journal. Je n'ai pas écrit ce code, mais son but est de ftp un fichier zip vers un serveur distant. Donc la question est ....

Sur quelle (s) ligne (s) ce code pourrait-il renvoyer une exception "L'index était en dehors des limites du tableau"?

FtpLib.FTPFactory ff = new FtpLib.FTPFactory(); 
try 

{ 
    ff.setRemoteHost(job.FTPHost); 
    ff.setRemoteUser(job.FTPUser); 
    ff.setRemotePass(job.FTPPW); 
    ff.login(); 
// Execute misc. extra commands 
foreach (string command in job.Commands) 
{ 
    if (log.IsDebugEnabled) 
     log.Debug("JOB: " + job.ID + " -- FTP Command \"" + command + "\" sent..."); 

    ff.sendCommand(command); 

    if (log.IsDebugEnabled) 
     log.Debug("JOB: " + job.ID + " --  Response: " + ff.getLastMessage()); 
} 

try 
{ 
    ff.mkdir(job.FTPRemoteDir); 
} 
catch (IOException) { } 

ff.chdir(job.FTPRemoteDir); 
ff.setBinaryMode(true); 

if (log.IsInfoEnabled) 
    log.Info("JOB: " + job.ID + " -- FTP UPLOAD: \"" + zipfile.Name + "\" to \"" + job.FTPHost + "/" + job.FTPRemoteDir + "/\""); 
ff.upload(zipfile.FullName); 
if (log.IsInfoEnabled) 
    log.Info("JOB: " + job.ID + " --  Completed."); 

bFTPSuccess = true; 
break; 

}

Merci à l'avance!

MISE À JOUR: Je pense que nous sommes tous plutôt d'accord que le problème va être dans le FTPLib, je vais voir si nous avons la source pour cela. J'ai découvert qu'il s'agit d'un bug obscur que le client ne peut même pas reproduire de manière cohérente, donc ce sera un point amusant. J'ai ajouté la journalisation de débogage supplémentaire en utilisant les fonctions Exception.StackTrace et Exception.ToString. Je mettrai à jour à nouveau une fois le problème résolu et j'essaierai d'attribuer la bonne réponse à la bonne personne, bien que tout le monde ait fait de bonnes suggestions. Merci pour l'aide!

Answer 1

Je vous suggère de consigner le journal Exception.StackTrace au point où vous êtes en train d'attraper l'exception hors limites. Exception.ToString() est également très utile, car il donne la plupart des informations importantes. Cela devrait vous indiquer l'endroit exact où l'exception est lancée (sans avoir à deviner). Attention cependant au code qui attrape une exception et la cache - Je vois que le code que vous avez posté a "catch (IOException) {}". Méfiez-vous également du code qui attrape une exception, puis lance une exception différente, qui masquera l'erreur d'origine.

Il ne devrait pas être nécessaire de boucler dans try ... catch lignes individuelles qui sont suspectes - tant que toute exception est interceptée à un certain moment dans la chaîne d'appel et connecté.

Answer 2

Sans connaître le reste du code qui pourrait être assez difficile à dire. La ligne qui se démarque pour moi:

ff.getLastMessage() 

mais qui est juste une supposition (si, par exemple, les messages sont stockés dans un tableau ou simliar et derniers extraits de ce)

Answer 3

Je ne pense que c'est l'une de ces lignes de code.

Ma première estimation serait quelque chose dans votre boucle foreach mais cela semble assez solide. Etes-vous sûr que c'est dans la partie du code?

Pouvez-vous coller la trace de la pile?

Answer 4

ff.getLastMessage() 

Que fait ce procédé? Comment obtient-il le dernier message? Si elle utilise quelque chose comme messages[messages.Count - 1] ou quelque chose de similaire, et que la collection de messages est vide, elle déclencherait cette erreur. Ce serait ma meilleure estimation.

Answer 5

Rien d'évident. Cela va se résumer à la mise en œuvre réelle de la FtpFactory (mon vote pour cause probable) et le journal.

Une fabrique peut conserver un tableau d'instances du type qu'elle crée si la création de ces types est coûteuse. Donc, la première fois que vous faites quelque chose qui pourrait nécessiter l'utilisation de l'une de ces instances ("ff.login") pourrait exposer le bogue.

Je vous suggère d'entourer toute tentative d'utilisation de l'usine avec un essai/attraper et enregistrer dans le journal où cela se produit. En outre, je suggère d'éviter d'utiliser cette usine de toute façon, car il a été écrit par quelqu'un avec peu de respect pour les normes et les pratiques (noms de méthode en minuscules?) Qui est un signe d'avertissement de malfaçons.

tl; dr: Ne faites pas confiance à votre usine ftp. C'est probablement nul.

Answer 6

Outre le poste de Will pour être complet:

 
FtpLib.FTPFactory ff = null; 
try 
{ 
    ff = new FtpLib.FTPFactory(); 
} 
catch(Exception ex) 
{ 
    // Log it 
} 

De plus, je ne pouvais pas aider à se demander, est le travail de connexion, qui est un autre endroit pour l'enrouler autour de bloc try/catch

Il se peut que la connexion échoue, et ff est utilisé pour exécuter les commandes et lève probablement cette exception - ne demandez pas pourquoi? Je soupçonne que ces routines FTP sont écrites par quelqu'un qui ne sait pas ce qui se passe ou mal écrit, regardez la méthode de connexion - tout en minuscule comme Will ci-dessus (bravo pour le signaler) mentionné.

Espérons que cela aide et la chasse aux bugs heureux ... Cordialement, Tom.

Answer 7

Fondamentalement, chaque appel de méthode unique est un candidat possible, y compris le constructeur et les propriétés. (Ils sont essentiellement des appels de méthode), les deux derniers sont bien probablement ceux qui ont le risque le plus faible (Ce serait une mise en œuvre bizarre soit)

plus plausible que je dirais est ff.getLastMessage()