Topic: Do you take exception?

[sinc]

How and when to use exceptions is something that's been an ongoing subject for debate for a long time.

On one hand, exceptions are very handy and convenient.  They help keep methods streamlined, with fewer nesting levels in the code.  And exceptions leave methods free to return values that are not status codes (e.g., a "Succeeded" code or an error code), which makes code easier to read.

On the other hand, there is typically some amount of overhead involved in the whole exception handling and trapping paradigm, which can slow code execution.  And then there is the strict-OO position that exceptions are akin to "Goto" statements, and therefore something that should be avoided on general principle.

How do people feel about exceptions in .NET?  From what I've seen, they seem to be rather popular.  I regularly see exceptions used in cases where a status code would work equally well.  In fact, .NET seems to be rather "exception-happy".

Has anyone come up with any good rules-of-thumb for when or when not to use exceptions in .NET?

[It's Alive!]

Interesting, I would like to hear opinions as well.

Some good reading here
http://msdn2.microsoft.com/en-us/library/ms229014.aspx
and
http://msdn2.microsoft.com/en-us/library/5b2yeyab.aspx

p.s. Personally I don’t worry about the performance hit with catching exceptions,

Dan

[MickD]

Exceptions should be used for just that - exceptions, but you quite often see them being abused to branch programs or return results as a result from an error that should be checked for to start with.
As you said Sinc, there is an overhead to all this as well as being a bad habit to get into.

When writing a routine to perform a task in C# or C/C++ I like to use a try/catch around the whole routine so that it insulates my routine from the main system. Using them for debugging is a fair enough call but even then it's better to know what you are likely to 'catch' and avoid it as best you can, having a try/catch to catch odd exceptions can be handy at this stage to turn up unexpected errors also.

[Glenn R]

And then there is the strict-OO position that exceptions are akin to "Goto" statements, and therefore something that should be avoided on general principle.

I beg your pardon? In all the reading and studying I've done on programming languages over the years, I've never heard of that one.

In general, use a try/catch/finally construct to trap exceptions that might be thrown. Make your own custom exception class if you have made your own custom class and throw new instances of your custom exception where it makes sense to do so.

Also, having sat back and navel gazed on this subject for a few moments I believe I understand why .net is, as you put it, quite exception friendly. Exceptions are built into the CTS/CLR so they are relatively cheap compared to some other languages and, here's the more important part I think, throwing exceptions teaches you to use try/catch/finally constructs just about everywhere - which can't be a bad thing.

Cheers,
Glenn.

[Kerry]

akin to "Goto" statements

.. Has me scratching my head too  ..


I've noticed exception handling used in some 'intersesting' situations ..
.. but believe they should be used to handle 'exceptional' situations, not as an extension to conditional or assertion algorithms.


That being said, there is a philosophical aspect that comes into play here ..

do you test to make sure a divisor is not zero { and advise the user, and branch accordingly } or just let an exception handler catch it ??  ... so much is attitude dependant.

[MickD]

.. but believe they should be used to handle 'exceptional' situations, not as an extension to conditional or assertion algorithms.

You said it so much better Kerry

[sinc]

And then there is the strict-OO position that exceptions are akin to "Goto" statements, and therefore something that should be avoided on general principle.

I beg your pardon? In all the reading and studying I've done on programming languages over the years, I've never heard of that one.

It basically comes down to the fact that, in many cases, the following two code snippets are functionally-identical.  Of course, there are some cases where it is definitely desirable to throw exceptions.  But from what I've seen so far in .NET, the first method below seems to be almost-never used, in favor of throwing exceptions.

Thus my thread.

Code: [Select]

// School of thought 1:  Exceptions should happen in exceptional conditions only
returnValue = someObject.Method();  // returns null on failure
if (returnValue) {
 performSomeFurtherTask();
}
else {
  printErrorMessage();
}


// School of thought 2:  Exceptions abound
try {
  returnValue = someObject.Method();  // throws exception on failure
  performSomeFurtherTask();
}
catch {
  printErrorMessage();
}


[Glenn R]

Well, it depends on your design. I use both methods depending on what I'm doing.

With respect to your example #1, it's quite valid in my opinion, to return a null reference and many AutoCAD and Microsoft api's do exactly this.
As an example, if I used an API function that returned a null reference and my design dictated that I need a valid reference, then I would throw a NullReferenceException.

At the end of the day, it's a question of style.

[MickD]

in regards to the if/else style I'd rather do a test and continue rather than a test and then something else, IOW I'd use

if(!result) { //process error}

goAboutMyBusinessNow_itsOk();

it seems like the same thing, the IL will tell the real story though.

[Bryco]

Sinc, I was trying to figure out how to do just that.
Maybe this is different or maybe not.
Converting a vba isclockwise function, I want the answer to be a bool. The problem is, if the polyline is self crossing there is a third possibility-  no good solution. Since this happens once in a blue moon I would rather make an error and stop the program than change the bool to an integer.
Not sure how to do it though.

[Glenn R]

...or, you make your return value a 'triple state' enum