Is it “bad” to use try-catch for flow control in .NET?

前端 未结 9 1060
天命终不由人
天命终不由人 2020-11-30 14:51

I just found in a project:

try
{
    myLabel.Text = school.SchoolName;
}
catch
{
    myPanel.Visible = false;
}

I want to talk to the devel

相关标签:
9条回答
  • 2020-11-30 15:32

    I think this is bad because it is coding against an exception for one and it will also inherit unnecessary overhead. Exceptions should only be caught if they are going to be handled in a specific way.

    Exceptions should be caught specifically for Exceptional cases that you can not predict, in this case it is a simple check to see if school can be null, in fact it is expected that school might be null (since the label is set nothing). If school was null and it should not have been than it should throw its own ArgumentNullException.

    0 讨论(0)
  • 2020-11-30 15:32

    I agree with everyone here--it's a horrible idea.

    There are a few cases in Java (I think they are mostly gone now, but there may still be some in external libraries) where you were required to catch an exception for certain "non-exception" cases.

    In general, when writing library code (well, any class actually), avoid using exceptions for ANYTHING that could possibly be avoided. If it's possible that a name field isn't set and that should cause an exception in a write() method, be sure to add an isValid() method so that you don't actually HAVE to catch the exception around the write to know there is a problem.

    (Bad Java code addendum): this "good" programming style virtually eliminates any need for checked exceptions in Java, and checked exceptions in Java are the Suck.

    0 讨论(0)
  • 2020-11-30 15:34

    Exceptions do incur runtime overhead, but it's probably negligible here. There will be a difference running in the debugger, but the built binaries should run at pretty much the same speed.

    Tell your developer that any chimp can make code the machine can read. Good code is written for human beings, not machines. If a null exception is the only thing you're worried about, then it's probably a bug in the user's code -- noone should ever try to assign null to anything that way. Use an Assert() statement instead.

    0 讨论(0)
  • 2020-11-30 15:35

    Check out this post on "Why not use exceptions as regular flow of control?"

    0 讨论(0)
  • 2020-11-30 15:42

    In my opinion this is poor because it could be made much more clear with an if statement:

    if (school != null) {
        myLabel.Text = school.SchoolName;
    }
    else {
        myPanel.Visible = false;
    }
    

    That will certainly avoid using exception handling unnecessarily and make the code's meaning very obvious.

    0 讨论(0)
  • 2020-11-30 15:45

    I never like using exceptions for flow control. Exceptions are expensive, and it is difficult to determine what the actual flow of a program with exceptions being thrown to reach other places in code. To me this is like using GoTo. This doesn't mean that you should avoid exceptions, but rather an exception should be just that, an exception to what should normally happen in the program.

    I think a worse part of the code, is that it's not even doing anything with the exception. There is no logging or even an explanation as to why the exception is being thrown.

    0 讨论(0)
提交回复
热议问题