Je regarde l'article C # - Objet de transfert de données sur les DTO sérialisables.
L'article comprend ce morceau de code:
public static string SerializeDTO(DTO dto) {
try {
XmlSerializer xmlSer = new XmlSerializer(dto.GetType());
StringWriter sWriter = new StringWriter();
xmlSer.Serialize(sWriter, dto);
return sWriter.ToString();
}
catch(Exception ex) {
throw ex;
}
}
Le reste de l'article semble sain d'esprit et raisonnable (pour un noob), mais ce try-catch-throw lève une WtfException ... N'est-ce pas exactement équivalent à ne pas gérer les exceptions du tout?
Ergo:
public static string SerializeDTO(DTO dto) {
XmlSerializer xmlSer = new XmlSerializer(dto.GetType());
StringWriter sWriter = new StringWriter();
xmlSer.Serialize(sWriter, dto);
return sWriter.ToString();
}
Ou est-ce que je manque quelque chose de fondamental sur la gestion des erreurs en C #? C'est à peu près la même chose que Java (moins les exceptions vérifiées), n'est-ce pas? ... Autrement dit, ils ont tous deux affiné C ++.
La question du débordement de la pile La différence entre relancer la capture sans paramètre et ne rien faire? semble soutenir mon affirmation selon laquelle essayer-attraper-jeter est un non-op.
ÉDITER:
Juste pour résumer pour tous ceux qui trouveront ce fil à l'avenir ...
NE PAS
try {
// Do stuff that might throw an exception
}
catch (Exception e) {
throw e; // This destroys the strack trace information!
}
Les informations de trace de pile peuvent être cruciales pour identifier la cause première du problème!
FAIRE
try {
// Do stuff that might throw an exception
}
catch (SqlException e) {
// Log it
if (e.ErrorCode != NO_ROW_ERROR) { // filter out NoDataFound.
// Do special cleanup, like maybe closing the "dirty" database connection.
throw; // This preserves the stack trace
}
}
catch (IOException e) {
// Log it
throw;
}
catch (Exception e) {
// Log it
throw new DAOException("Excrement occurred", e); // wrapped & chained exceptions (just like java).
}
finally {
// Normal clean goes here (like closing open files).
}
Attrapez les exceptions les plus spécifiques avant les moins spécifiques (tout comme Java).
Références: