I started to think about everything that's wrong with the authors code example and the more I got into it the more I realized the entire problem is wrong. "Our

I started to think about everything that's wrong with the authors code example and the more I got into it the more I realized the entire problem is wrong. "Our goal is to write a function that takes a list of previously released versions and a user-provided version string, which then returns the parsed number or reports an error." A function named CheckNextVersion should never even raise an exception because it expects bad input. It probably also shouldn't double up as the ParseNextVersion function as well. But I understand the author wanting to combine these operations and conveniently get an error message out that can be displayed to the user. But as a damning example of exception handling, it's just bad design. So even if we accept the design, his method is horribly over-thought with regards to error handling. Either it should catch within it's body all potential exceptions and raise a single InvalidVersionException or it should catch nothing and the code above should catch everything and display the message to the user. All the work catching and rethrowing different exception types adds no value given the purpose of the method.