Discussion :

[Papy214]

Bonjour

Je me pose une question sur la meilleure manière de coder le retour d'une "fonction".

Voilà un exemple :

Solution 1 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
        public void GetConnection(string fileName, out SqliteConnection? sqliteConnection)
        {
            sqliteConnection = new SqliteConnection();
 
            try
            {
                string connectionString = $"Data Source={fileName}";
                SQLitePCL.raw.SetProvider(new SQLitePCL.SQLite3Provider_e_sqlite3());
                sqliteConnection = new SqliteConnection(connectionString);
            }
            catch
            {
                sqliteConnection = null;
            }
        }

Solution 2 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
        public SqliteConnection? SqliteConnection2(string fileName)
        {
            var sqliteConnection = new SqliteConnection();
 
            try
            {
                string connectionString = $"Data Source={fileName}";
                SQLitePCL.raw.SetProvider(new SQLitePCL.SQLite3Provider_e_sqlite3());
                sqliteConnection = new SqliteConnection(connectionString);
            }
            catch
            {
                sqliteConnection = null;
            }
 
            return sqliteConnection;
        }

Qu'est-ce qui pour vous est le mieux ? Le plus propre, plus académique ... etc

[nouby]

Salut !
je suis pas un pro, mais il me parait logique que le return soit placé juste à la sortie de la fonction/procédure.

et au fait, dans la première, je vois pas le return.

[tatayo]

Bonjour,

et au fait, dans la première, je vois pas le return.

Le type de retour de la première est void, donc il n'y a pas besoin de return.
Pour moi il est plus logique d'utiliser la seconde syntaxe.

Ta fonction "génère" une instance de SqlConnection, donc c'est ce qui doit être renvoyé.

Tatayo.

[Papy214]

Ta fonction "génère" une instance de SqlConnection, donc c'est ce qui doit être renvoyé.

Donc la meilleure syntaxe est celle qui renvoie une instance déclarée dans la procédure plutôt que celle passée en paramètre "out".

Ok merci

[Papy214]

Salut !
je suis pas un pro, mais il me parait logique que le return soit placé juste à la sortie de la fonction/procédure.

et au fait, dans la première, je vois pas le return.

pas besoin de return, c'est la variable passée en paramètre qui est créée et récupérée par l'appelant

[umfred]

Je n'avais pas vu le "out" à la 1ère lecture, je disais que tu passais par une variable globale

Je pense que les 2 sont équivalentes, mais que le "out" est plutôt à utiliser lorsqu'on veut modifier un paramètre (passage par référence). Ici comme tu créés une connexion, il me semble plus logique de retourner cette connexion via le return

[nouby]

Merci à vous deux, j'ai appris un bon truc !
Désolé, ma réponse était pas top, mais bon ça m'a permit d'apprendre

[Papy214]

Merci à vous deux, j'ai appris un bon truc !
Désolé, ma réponse était pas top, mais bon ça m'a permit d'apprendre

Toute occasion d'apprendre est bonne "à {p} prendre"

[Artemus24]

Salut à tous.

Ce qui conditionne le choix d'une fonction ou d'une procédure est l'usage que tu vas en faire dans tes traitements.
J'ai tendance à utilisé une fonction quand je retourne des nombres.
A l'inverse, j'utilise plutôt une procédure quand je fais soit de la récursivité ou soit de la manipulation de tableaux.

Dans ton exemple, les deux déclarations sont équivalentes.

[bacelar]

Ma remarque à 2 balles, je ne vois pas l'intérêt de cacher les exceptions à l'appelant, qui lui, doit savoir comment réagir en fonction du type d'exception.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
public SqliteConnection getSqliteConnection(string fileName)
{
    string connectionString = $"Data Source={fileName}";
    SQLitePCL.raw.SetProvider(new SQLitePCL.SQLite3Provider_e_sqlite3());
 
    return new SqliteConnection(connectionString);
}

Code qui sera plus proche d'une version plus évoluée qui utilisera toutes les fonctionnalités d'un ".config" (si ça existe encore ).

P.S.: Je suis pas fan de ce qui m'apparait comme un effet de bord : "SetProvider".

[Papy214]

Pour moi il n'y a pas de remarque à "deux balles". Tout est bon à prendre en compte.

Pour le SetProvider, il n'est plus à l'ordre du jour depuis que je suis passé de Microsoft.Data.SQlite à System.Data.SQLite.

Concernant la potentielle erreur que je voulais traiter à cet endroit, j'ai surement un peu trop l'habitude de découper mon code en éléments imbriqués et parfois, dans la hiérarchie d'appels, j'ai peur de rater une étape dans la gestion des exceptions. Alors je les traite à tort de cette façon. Mais je m'améliore chaque jour