résumé em> On m'a donné une tâche pour configurer un logiciel de gestion (pour un artiste à petite échelle, leur matériel peut donc certainement faire face), cependant, je préférerais Pour que cela soit aussi efficace que possible avant de leur donner. La principale fonctionnalité est terminée, et maintenant, il s'agit principalement de toucher et d'optimiser. P> code em> p>
DateTime DueDate;
try
{
DateTime.TryParse(dteCommission.SelectedDate.Value.Date.ToShortDateString(),
out DueDate);
}
catch(Exception E)
{
MessageBox.Show("Due Date wasn't set. Defaulting to current date.", "Alert",
MessageBoxButton.OK, MessageBoxImage.Warning);
DueDate = DateTime.Parse(DateTime.Now.ToShortDateString());
}
4 Réponses :
Exception E n'a été utilisée que pour l'obtenir rapidement et la véritable exception est connue. L'erreur donnée est "L'objet nullable doit avoir une valeur". Système.invalidoperationException p>
Comment sauriez-vous que dans l'exécution de ce serait une exception différente? Disons nullreferenceException (par exemple) peut-être. N'oubliez pas que toutes les exceptions implémentent l'objet d'exception. P>
est-il préférable de gérer cela comme je le fais ou si cela fonctionnerait-il mieux? P> BlockQuote>
Vous devez mieux gérer les erreurs. Vous savez que cela pourrait être nullable, vous devez donc vérifier s'il a une valeur avant de continuer. Vous devriez rechercher des avertissements et les gérer avec élégance. P>
Et si oui, comment allais-je continuer à la mettre en œuvre? P> blockQuote>
xxx pré> blockquote>
C'était ce que j'étais après, merci. Avez-vous des suggestions où je devrais aller pour réviser la manipulation des erreurs?
Si vous êtes déterminé à utiliser Il est donc préférable d'aller avec la manipulation des exceptions. P> pour la première approche: p> pour le second cas que vous pouvez aller avec: p> Tryparse code>, c'est une meilleure approche pour aller avec
if-ele code> qui dépend de la sortie du
Tryparse code> méthode. Mais si vous utilisez
parse code>, il est probable que vous vous retrouvez avec l'une de ces exceptions:
Comme vous utilisez déjà et ensuite, tryparse code> Il n'est pas nécessaire d'utiliser
essayer ... Catch code> bloc. Pas seulement c'est inefficace, il n'est pas non plus propre. Il suffit de prendre la valeur de retour de
datetime.trypsarse code> et prenez la décision. P>
var isdate = datetime.tryparse (dtecommission.selecteddate.value.date.toshortdateSestring (), code> p>
if (isdate) {...} else {...} code> p>
J'accepterais cela, mais en utilisant malheureusement tryparse code> a jeté une erreur.
Dans ce cas, il est très probable que dans ' dtecommission.selecteddate.value.date "soit la date code> valeur" ou
date code> est
null code>, donc Vous devriez vérifier la santé mentale de cet objet, puis utiliser ce qui précède comme suggéré.
J'aimerais suggérer d'utiliser si d'autre déclaration pour un tel scénario plutôt que sur l'exception, il sera également optimisé et vous permet de donner un message de manière significative spécifique au scénario. P>
La manipulation des exceptions doit être utilisée uniquement pour gérer des scénarios inconnus. p>
Vous devriez éviter la manipulation des exceptions dans tous les cas à moins d'une situation exceptionnelle. C'est pourquoi ils s'appellent des exceptions.
Il y a plusieurs choses en cours ici, et il n'est pas clair s'ils sont pertinents pour votre question. Par exemple, vous semblez convertir des denttimes en cordes et en arrière sur DateTimes, et ce n'est pas clair pour moi pourquoi. Si vous souhaitez supprimer le composant TIME de la journée, utilisez simplement la propriété
datetime.date code>. Mais ce n'est pas la source de votre exception, il semble juste d'être une complexité supplémentaire non liée à votre question.
Quoi que vous fassiez, essayez de toujours éviter de saisir toute exception de type
exception code> sauf si vous prévoyez de repousser.