0

I basically read across the entire internet that exceptions are bad, slow and should be avoided whenever possible. This confuses me because I thought I have a "valid" case to use exceptions.

Consider an input parser which transforms a string into an expression tree, that a calculator can evaluate. For me this seems perfectly suited for exceptions, see the following Pseudo-Code

try:
    expression_tree = input_parser.parse(user_input);

    print "Result: " , calculator.evaluate(expression_tree);

catch division_by_zero e:
    print "Error: Division by zero near: " , e.code_window();

catch matrix_dimension e:
    print "Error: Matrix dimension don't match near: ", e.code_window();

catch ...

Since I do not plan to fix the error, just catch it and then ask for a new input, the speed factor should be of no concern. Furthermore this makes the code well readable and easy to handle, as I don't need error codes or manual jumps / premature exits from functions. But as I've stated, the overall attitude towards exceptions makes me doubt myself.

infinitezero
  • 163
  • 7
  • 2
    Does this answer your question? [Are exceptions as control flow considered a serious antipattern? If so, Why?](https://softwareengineering.stackexchange.com/questions/189222/are-exceptions-as-control-flow-considered-a-serious-antipattern-if-so-why) – gnat Jun 13 '20 at 18:04
  • 1
    "I basically read across the entire internet" Try another internet, you obviously are not using the one most of us do. – Martin Maat Jun 14 '20 at 05:30
  • The answers already mark the start of the general "pros and cons of exception" discussion. Maybe you should not ask for "good practice", but just for feedback on your specific coding example. – Oliver Meyer Jun 14 '20 at 06:55

2 Answers2

2

There are no shortage of complaints about throwing and catching both within the same method.  These are considered a form of goto, considered harmful.

Throwing an exception when we don't want to proceed — e.g. with parsing — is different and is reasonable usage of exceptions.

However, in your code you might abstract the exceptions a bit by making one root exception, say, an abstract parse_error class with a method to print itself.  Your parser will then have a bit more flexibility in generating error messages, and your outer handler won't have to check for all the specific exceptions.  (Of course, division by zero shouldn't happen in the parser — if it does then the parser is really more than that, like an interpreter, or possibly an optimizer.)

Erik Eidt
  • 33,282
  • 5
  • 57
  • 91
  • Maybe enhance your answer by adding something about the expected inner workings of parse, that make exceptions a suitable choice. @Martin Maat said: "[exceptions] are about backtracking a number of steps and typically aborting an operation" Here, they might allow to exit the parse function when an error is detected without cluttering the whole parser with clean up code. – Oliver Meyer Jun 14 '20 at 07:05
1

Exceptions should be used for exceptional cases. A parse error is not exceptional; an input that can be parsed correctly is probably more exceptional: -(

gnasher729
  • 42,090
  • 4
  • 59
  • 119
  • While I agree that parsable input is the exception, can your program continue executing after encountering a parse error? If not, throw an exception. Halt the program. I always thought "exceptions are for exceptional conditions" did not quite convey the right message. Exceptions are the hand grenade of programming. Throw it when there is literally no other path forward, and moving forward is riskier than crashing the entire application. – Greg Burghardt Jun 14 '20 at 03:07
  • @Greg Burgardt Exceptions are not about crashing the application. They are about backtracking a number of steps and typically aborting an operation that cannot be completed for some anticipated yet uncommon reason. You make is sound uncontrolled and destructive which isn't right. – Martin Maat Jun 14 '20 at 05:44
  • @MartinMaat: from the perspective of the thrower it is uncontrolled and destructive. I do like the phrasing "They are about backtracking a number of steps and typically aborting an operation." That's a less dramatic way of saying it. – Greg Burghardt Jun 14 '20 at 13:00