6
votes

L'objet n'est pas disposé le long de tous les chemins d'exécution

J'ai le code suivant.

private DataTable LoadSMSCellProviders()
{
    string sqlQuery = "Select * from SMSAddress";
    DataTable dt = new DataTable();
    using (SqlConnection conn = new SqlConnection(Utility.ConnString))
    {
        using (SqlCommand command = new SqlCommand(sqlQuery, conn))
        {
            SqlDataAdapter adapter = new SqlDataAdapter(command);
            adapter.Fill(dt);
            return dt;
        }
    }
}


2 commentaires

L'idée est que vous devez en disposer d'une exception.


Il incombe à la méthode d'appel à LoadsMscellProviders () pour disposer du fichier renvoyé .


4 Réponses :


7
votes

Vous devez en débarrasser lors d'une exception. Comme ceci. XXX

L'idée est que si une exception se produit, il n'ya aucun moyen de disposer du datatable car il ne sera pas transmis à l'appelant. Donc, c'est le motif qui rendra l'analyse de code heureux.


5 commentaires

Votre code dispose de la table de données même lorsqu'une exception ne se produit pas!


Pourquoi ne pas utiliser une déclaration à l'aide de DataTable aussi?


devrait être essayer attraper, ne pas essayer enfin


@San Ouais, j'ai réparé ça maintenant.


@ SELMAN22: Parce que vous voulez le disposer uniquement en cas d'exception, pas toujours.



0
votes

L'analyse de code vous avertit que cet objet peut ne pas être disposé. Comme @juharrr suggère à juste titre, vous devez neutraliser le chemin de code dans lequel une exception se produit, sinon l'objet ne sera pas retourné et qu'il ne sera pas explicitement éliminé. Cela se débarrassera de l'avertissement.


4 commentaires

Il appelle spécifiquement le chemin d'exécution lorsqu'une exception est lancée.


Pour autant que je me souvienne, il restera toujours plaindre même avec votre try-catch, car il existe un chemin de code où l'objet sort de la portée sans être disposé (celui où vous le retournez).


Non, il ne devrait pas se plaindre du retour d'un objet jetable non disposé.


Merci. Je viens de tester et tu as absolument raison. La dernière fois que j'ai vérifié, c'était il y a longtemps, j'ai sans doute mis en place le modèle de manière incorrecte sans se rendre compte.



-2
votes

Vérifiez la réponse @juharRarr et après avoir utilisé le jeu de données et que vous n'en avez plus besoin, il suffit de faire

using(dt){}


5 commentaires

La méthode renvoie que datatable , vous ne devriez pas le disposer!


@Andrew Je me suis fait clair après qu'il utilise le DT, pas dans la méthode. C'était un rappel amical parce que nous sommes vendredi: D


Mais vous devez savoir quand exactement la dernière fois que vous utilisez ce dataTable . Personnellement, j'ai jamais vu un en utilisant sans la création d'objet en ligne.


Je conviens que les appelants de la méthode devraient également disposer du de préférence avec un à l'aide de l'instruction à moins que cela ne soit passé d'autre niveau, bien sûr.


J'utilise toujours en utilisant (y compris ce comportement dans la question OP) comme un rappel que j'ai toujours à utiliser en utilisant (tout autre cas de vie normal)



3
votes

Fire l'outil. Les datables n'ont pas besoin d'être disposés. Ils sont isisposables parce qu'ils héritent de l'icomponent, mais leur disposition () la méthode ne fait rien. Je trouve qu'il est dégoûtant que le propre outil de MS ne le sait pas.


0 commentaires