Question

1. If a method fails to do what it says it will do (e.g. if SendEmail fails to send an email), it should throw an exception. I blogged about this in-depth (optional read): Do your work, or throw an exception – example. It seems this idea is already a convention, even though I have not found it described elsewhere. “Exceptions are for exceptional cases” is a different guideline requiring an additional guideline “Do not use exceptions for normal flow control”, and requiring discussion on what is “exceptional”. “Do your work or throw an exception” is as unambiguous as the responsibility of the method (which already should be unambiguous).
2. All methods, including “Try” methods (e.g. TrySendEmail), should always throw if some unrecoverable error happens–something that adversely affects other features of the app, not just the functionality being attempted, such as RamChipExplodedException. That is, even though “TrySendEmail” technically accomplishes what the name indicates (it tries to send an email), it should still throw an exception if the RAM explodes (if it can even do that… you get my drift).
3. “Try” methods should be used only in special cases.

Are these always good guidelines (i.e., are there any exceptions (pun!) to the rule)? Can you think of any others not covered by these?

To clarify, I’m not asking for more specific rules of thumb to help follow these guidelines; I’m looking for additional guidelines.

Answer 1

For me, the #1 rule is: avoid exceptions in normal flow. When you debug, make sure all thrown exceptions are signalled. It is the first indication that your code is working the way you designed it.

TryXXX should not throw exceptions unless you violate the design contract. So for instance TrySendMail() may throw if you pass in a null pointer as the text for the email.
You need TryXXX methods if there is no way to get “normal flow” exception free without them. So for parsing data, they’re essential, I would not reccomend a TryLogin function.

“Do your work or throw” is a good starting point, but I would not make it a dogma. I am OK with a collection returning -1 if you ask IndexOf an item that isn’t there. You can discuss with your colleages where you want to draw the line and put in your coding standards.

I also use exceptions a lot to label control paths that I think are not used. For instance if I am forced to write a GetHashCode function that I assume won’t be called, I make it throw.