!(How to best use a try catch block) [modified]

[supercat9]

If something totally unexpected happens (like e.g. the 'ObjectDisposed' you mentioned), there should be a general top level exception handler at the application level, but for sure such an exception must never be swallowed silently by the executing code. Not in a million years, in no circumstance whatsoever! That depends what one is trying to do. Would people like Visual Studio very much if it died any time an exception occurred while evaluating expressions in the Watch window? Or is the proper action to show the problematic expression with an indication that it cannot be evaluated? If a program is supposed to graph a function, it may at times be unclear the best way to handle an exception. If one is trying to graph an expression like f(x)=1/x, it's best that the problematic case at x=0 be swallowed, while graphing is allowed to continue on the other side. On the other hand, if the function is one which will always throw an exception, calling the function 1,000 times while drawing the graph will cause 1,000 exceptions to be thrown. Swallowing exceptions in a fashion that hides any indication of what type of exception occurred seems like a bad idea, but it would seem there are many situations where a calling application is merely interested in whether or not an operation worked, and not what went wrong if it didn't.

[User 4483848]

I don't like returning -1 for an error (particularly in this case) because -1 could be a valid result. eg. the values are all -1. There are a couple of nice solutions I can think of. One would be to use a nullable type ie. double?. The other way would be to let an exception be thrown or throw your own exceptions. Only looking at the first four elements is probably the worst thing IMHO though. What do you think of this?

public double CrappyTotal
{
get
{
double total = 0;

    foreach (var d in this.SomeItem.Details)
    {
        total += d.Value;
    }

    return total / (double)this.SomeItem.Details.Count;
}

}

No exception handling :mad:. I would be happy without error handling. I could add a check for nulls at the start, but I don't think it's worth the time. It would probably depend how and where it was being used though. So, are there people out there who insist that every exception must be handled?

[OriginalGriff]

supercat9 wrote:

Would people like Visual Studio very much if it died any time an exception occurred while evaluating expressions in the Watch window? Or is the proper action to show the problematic expression with an indication that it cannot be evaluated?

I'm not sure what your argument is here. VS dying under those circumstances isn't "swallowing the exception", it is ignoring it completely. VS reporting the problem isn't swallowing the exception either, it is processing it and reporting the existance of a problem - exactly what exceptions are there for. Swallowing an exception is (IMHO) "pretending it didn't happen" and carrying on regardless. If a problem occurs saving my work every ten minutes and the exception gets swallowed, I am going to be a very unhappy bunny when I find out later it was all lost!

No trees were harmed in the sending of this message; however, a significant number of electrons were slightly inconvenienced. This message is made of fully recyclable Zeros and Ones

[singh iz king]

Yes, That is one of the ways I suggested, but also added that if you are calculating an average, then the name should probably reflect that as well :)

[supercat9]

VS reporting the problem isn't swallowing the exception either, it is processing it and reporting the existance of a problem - exactly what exceptions are there for. The "-1" return seems overly vague as to what problem occurred when computing the data, but it does indicate that a problem occurred. I would not expect the caller of a function like the one given to ignore the return value. It may not process it particularly as an error, but it would probably store it someplace. Suppose the objective is to produce a table showing various data associated with a bunch of people; for whatever reason, certain data will be unavailable for certain people. Exceptions would be appropriate if one's objective was to leave unprocessed any person for whom some information could not be retrieved correctly. Return codes are more appropriate if the objective is to produce a table in which computable values are filled in and uncomputable values show "N/A".

[mateotrek]

Unaveragely craptastic!