ffeatools error changes

Issue #13 resolved
Robert Welch created an issue

EDIT: The modifications due to this issue can now be found in the branch ffea-polish and a few earlier commits to ffea_surface.py.

Here's an explanation of the rationale behind them, and how I think we should handle errors in the future.

The changes address a few anti-patterns that were present, such as

  • The modules would catch exceptions as part of their normal initialisation procedures (for example, an IOError) meaning that any error that occurred there would be passed over and cause problems later in the program that would be difficult for the user to trace. For example, a user could load a filename with a typo in it, which would generate a perfectly valid object, just a blank one.
  • Try\except statements were found within other try\except statements. The end result of this is that only the outer exception is thrown, which means users are deprived of more useful information in the inner statement.
  • Error handling lacked specificity; often methods would try\except all exceptions, and on any exception they would just disregard everything and self.reset(). Again, a user trying to find the source of an exception would be in for a lot of trouble, they might not even know that one had occurred.
  • Errors, warnings and regular messages would be printed to the terminal with no context. This caused me a few problems, because some messages that are part of the normal init procedure look(ed) like errors. From now on, any message that does not raise an exception is not an error.

Comments (4)

  1. Log in to comment