抛出异常VS返回错误尝试,抓住,最后 [英] Throw Exception VS Return Error within a Try,Catch,Finally

查看:399
本文介绍了抛出异常VS返回错误尝试,抓住,最后的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我很确定我已经知道答案了,但是我仍然很好奇,在Try,Catch,Finally(阻止),阻止 - 处理一个错误的意见,但是当你重复你的时候。 / em>



BTW - 我不是在谈论用户输入 - 但是使用它作为一个例子,因为它是清楚和简短



考虑这一段代码...

  try {
if(success){
return someSuccessMessage;
}
else {
logError(用户输入格式不正确);
return someErrorMessage; //重复本身
}
}
catch(Exception ex){
logError(ex.Message);
return someErrorMessage; //重复本身
}

说我们有一个功能,如果失败我们想要返回一个错误信息,因为异常是无关紧要的 - 我们的功能没有成功,用户不需要任何额外的细节。



我一直坚信如果你可以处理错误,避免异常 - 因为它不再是例外,但是我想知道关于避免重复你自己的意见...你可以做以下事情,以避免重复你自己...

  try {
if(success){
return someSuccessMessage;
}
else {
抛出新异常(用户输入格式不正确);
}
}
catch(Exception ex){
logError(ex.Message);
return someErrorMessage;
}

这不是最好的例子,但我要简洁重复代码的点。



已知异常会导致性能损失,但是对这种情况有什么想法?

解决方案

我在这里质疑分离问题。除非这个功能是UI的一部分,否则它不应该关注错误消息。它应该抛出异常。该方法的调用者(如果它是UI的一部分)可能会产生一个错误消息以进行显示。如果调用者是一个Web服务,那么它会想要生成一个SOAP错误,它可能不会使用相同的消息(如果根本使用任何消息)。



我也强烈建议你记录ex.ToString()而不是ex.Message。


I'm pretty sure I already know the answer, but I'm still curious what the opinion is on handling an error within a Try,Catch,Finally block -- but when you're repeating yourself.

BTW - I'm not talking about User Input - but using that for an example because it is clear and short

Consider this bit of code...

try {    
    if (success) {
        return someSuccessMessage;
    }
    else {
        logError("User input not correct format");
        return someErrorMessage; // repeats itself
    }
}
catch (Exception ex) {
    logError(ex.Message);
    return someErrorMessage; // repeats itself
}

Say we have a function, that if it fails we want to return an error message because the exception is irrelevant -- our function did not succeed and the user doesn't need any additional detail.

I've always held the belief that if you can handle the error, avoid the exception -- since it isn't exceptional anymore, but I wondered the opinion about avoiding repeating yourself as well... You could do the following to avoid repeating yourself...

try {    
    if (success) {
        return someSuccessMessage;
    }
    else {
        throw new Exception("User input not correct format");
    }
}
catch (Exception ex) {
    logError(ex.Message);
    return someErrorMessage;
}

This isn't the best example, but I was going for brevity to make the point of repeating code.

Exceptions are known to incur a performance penalty, but what are the thoughts about a situation like this?

解决方案

I question the separation of concerns here. Unless this function is part of the UI, it should not concern itself with error messages. It should be throwing exceptions instead. The caller of this method, if it's part of the UI, might want to produce an error message for display. If the caller were a web service, then it would want to produce a SOAP Fault, which might not use the same message (if it used any message at all).

I would also strongly suggest you log ex.ToString() and not ex.Message.

这篇关于抛出异常VS返回错误尝试,抓住,最后的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆