How, exactly should I be using exceptions?_问答_开发者

Pretty new to C#, and I'd like to know how should I be using exceptions? I mean, not a mechanics level, but at a good practice level.

I'll use for example my calculator which tokenizes and the converts to RPN and solves problems given in RPN.

During the tokenizing step there's various invalid inp开发者_StackOverflowuts, say "7.7.8" or "^&##", should I have separate exceptions for unknown symbols and invalid numbers? Is it wrong to say have a single exception and then a method in it containing the kind of error, to be given to the user?

I've really not been able to find much material on this kind of thing, so I thought I'd ask people with more experience than me.

-----Edit:

Thanks everyone for your awesome responses, I learned a ton today :) about my question, and even more for that matter.

Think about your lexer from the perspective of preconditions and postconditions. Here are two ways to design a lexer :

A lexer is a device which takes in a well-formed input string and outputs a lexical analysis. The input string is required to be well-formed; if it is not then the lexical analyzer fails with an exception.
A lexer is a device which takes an input string and produces a lexical analysis. Lexical analysis includes identification of and analysis of error conditions.

Do you know that the string you're going to pass in is correct, and you want an exception in the exceptional circumstance that it is incorrect? Or do you not know that the string is correct, and you wish the lexer to determine that?

In the former case, throw an exception. In the latter case, make the error analysis part of the output of the lexer.

Basically what I'm saying is do not produce vexing exceptions. Vexing exceptions are extremely irritating. If the caller of your code is calling it to determine whether the string is correct then they don't want that information in the form of an exception, they want it in the form of a data object that represents the error analysis. If the purpose of the code is to produce an error analysis then produce such an analysis as the normal operation of the method. Do not embed the analysis in an exception and make someone trap the exception in order to get it.

In my experience you should not use exceptions as part of the logic or control flow of the code. You should use it when there is a true exception. In your case, that would be, for instance, when there is an illegal character, character which shouldn't be there in the first place. If, however, the function is validating the string, you should not throw an exception when you find an illegal character, at least that is my opinion.

I use exceptions when database or file that "should" be there cannot be found, when a key/pair value is missing when it ought not to be etc.

Create exceptions for programmers, not users. Think what would be useful to a programmer calling your method?

If there is specialized error handling code they should consider writing for a specific cause of an exception, then provide a specific type of exception so they can have a 'catch' block specifically for it.

If the error handling code they should write is generic across various exception causes, then provide a more general type exception so they only have to code against that one.

This is a good reference on the best practices of exception handling in .Net.

http://www.codeproject.com/KB/architecture/exceptionbestpractices.aspx

A rule of thumb I like for determining if an exception is appropriate: If a function promises to do something and does not do it, it should throw an exception. A simple example would be Parse vs TryParse. Notice that the Parse functions promise to parse a string, then throw an exception if they cannot (e.g., because the string is in the wrong format). TryParse promises to try to parse, so it does not throw exceptions in if it cannot parse. In short, if your function makes a promise and fails to fulfill it, you should throw an exception.

Alternatively: do not throw an exception unless the preconditions of your function are unsatisfied. I interpret Eric Lippert's Vexing Exceptions as a discussion on what types of preconditions are inappropriate.

The general rule is KISS. You should only throw/create exceptions if you have need. There is no need to create a whole suite of exceptions if no one is every going to catch it.

In your case you could

Throw an InvalidArgument or create your own indicating that it is invalid user input.
Give a detailed error messages explaining what the problem was.

If you find that you are catching the exception and parsing the message and taking actions then its time to create custom exception/exceptions.

You could create a custom exception that has a "type" field, but any type of design that is dependent on exceptions is a bad one.

Exception should be for exceptional case, user input is not one of those case.

This question might help you When to throw an Exception

Use validation instead : Winform ui validation

all of your parsing exceptions should at least share a common base class so that the caller can catch any parsing exception without listing them all in the catch clause (and potentially forgetting one).

you can go down the road of making a taxonomy of subclasses but i wouldn't bother making such explicit distinctions until you have a need to do so. if the calling program takes the same action for all parsing errors then they can all be of the same class, varying only by display message. if it becomes clear that certain errors need to be handled differently, make a subclass. design around use cases.

as an aside: i think a given method should throw an exception if it cannot deliver what it promises, thus protecting the developer from assuming success in the case of failure. deciding which promises to make is a greater design question and you can look at existing parsing APIs for inspiration.