Something that doesn't happen on a typical run of the program. I wouldn't put a number on it, but if you were to imagine your program being run many times, you should not expect an exception to be thrown at all during a large percentage of those runs. Generally, no user errors, since users make errors all the time. Applications can be different however, so it's only a rule of thumb.Originally Posted by Elkvis
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
That seems like a waste of exceptions. Exceptions are good for breaking the flow of code. That is, if something happens that means you need to abort your program flow, then exceptions are good. That usually means errors.
Of course, we must define an error. It might be perfectly fine for a function to not find any results and it not being an error. Based on what the OP said about the requirements of the whole thing, it looks like syntax errors might be a good exception, but no match might not be a good exception.
I think that exceptions are for three things: enforcing program constraints, pre-conditions, and post-conditions. A program constraint is a rule that can never be broken, so it is a logical error. Not every program has constraints, but purely for example, "divide by zero" is one. As for what pre-conditions and post-conditions are, they express what should be true before and after something happens; rather a way of saying exactly what a function should do. I hope that's not too much of a lecture, but all that covers a great deal of exceptional crap.
The one reason user errors aren't exceptions I think, is because they normally shouldn't be able to break constraints in any non-trivial program. If you haven't sanitized your input then the program is just too brittle.
IMO, user errors are exceptions, because input to any function must be sane. That is, if a user makes an error, it should fail the pre-condition for any given function that processes the input.
Absolutely, but the user should be allowed to fail as many times as he wants. That's why you write code to validate things, because exceptions aren't flow control. If a user makes a mistake, an exception being thrown isn't as simple, or as user-friendly, as rejecting the input and going another iteration into a loop. I think it's far too easy to write exception code that forces the user to restart the program just so that correct input is provided.
You're right, but there is where different kinds of exceptions are useful. Incorrect input? Then throw an incorrect input exception.
I mean, if you are doing a parsing routine, then trying to parse entered syntax first and then try to extract the needed information is a waste of code. In this case, throwing a syntax error directly in the parsing routine that extracts information would be more useful.
When it comes to a GUI, then it's typically easier to validate all input before processing it. It's easy to simply show an error message and return from the command handler function.
This might be an example of how the application simply recovers from the error and asks the user for new input:
It doesn't even quit the loop.Code:for (;;) { try { std::cout << "Give me some input: "; std::cin >> input; std::cout << "\n"; process_input(input); std::cout << "OK!"; } catch (const bad_input& e) { std::cout << "Invalid input! Details: " << e.what(); } catch (const std::exception& e) { std::cout << "Uh-oh. Something bad happened. Details: " << e.what(); } }
That's not a good example. Parsing can mean extracting.mean, if you are doing a parsing routine, then trying to parse entered syntax first and then try to extract the needed information is a waste of code. In this case, throwing a syntax error directly in the parsing routine that extracts information would be more useful.
In such a case, validation is extraction and there are no real constraints. Whatever's supplied is either conforming or not.
But that is the point. If it's not conforming, it's a user error. And that means you have to throw an exception for invalid input.
But I don't need an exception to tell me anything. I know the input is bad already.
But it seems that exceptions provide the easiest way to incorporate that knowledge into the program logic.
Not really. You have to test the input regardless whether you choose to use exceptions or not. With exceptions, you write the test code somewhere, and it can end in a throw, and you write the code that catches the exception somewhere else out of sight. You're actually breaking up a cohesive unit of work. I'm not for that.
Then, let us picture a scenario: a compiler.
You write the code, the compiler parses it and outputs an executable.
In pseudo code, how would you write this (with or without exceptions)?
What happens if one step fails?
Can you even tell me the steps?The linker outputs the executable, you know. Why don't you ask me another loaded question?
*shrug* I figured it would be a good example.
I mean, it doesn't need to be perfect. Something along the lines of...
Parse(); // Translates code into internal structures
Optimize();
WriteEXE();
Or something.
No, your question doesn't make any sense. I'd like it if you'd work it out on your own, if you're really committed, how you can use exceptions in example foo without breaking up the testing part and the conditional branching in input routines. Maybe, just maybe, if you give up I've changed your mind for once.
