Eu estou vendo o artigo C # - Data Transfer Object em DTOs serializáveis.
O artigo inclui este pedaço de código:
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;
}
}
O restante do artigo parece sensato e razoável (para um noob), mas esse try-catch-throw lança uma WtfException ... Isso não é exatamente equivalente a não lidar com exceções?
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 estou perdendo algo fundamental sobre o tratamento de erros em c #? É praticamente o mesmo que Java (menos exceções verificadas), não é? ... Ou seja, ambos refinaram o C ++.
A questão do estouro de pilha A diferença entre relançar a captura sem parâmetros e não fazer nada? parece apoiar minha afirmação de que o try-catch-throw é um não-op.
EDITAR:
Apenas para resumir para quem encontrar este tópico no futuro ...
NÃO
try {
// Do stuff that might throw an exception
}
catch (Exception e) {
throw e; // This destroys the strack trace information!
}
As informações de rastreamento da pilha podem ser cruciais para identificar a causa raiz do problema!
FAZ
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).
}
Capte as exceções mais específicas antes das menos específicas (assim como Java).
Referências: