Consider using specific exceptions rather than generic `Exception`

[xylar]

I don't find the exceptions raised by jigsawpy to be very intuitive, and I think that might be true for most python users.

As an example:

jigsaw-python/jigsawpy/savemsh.py

Line 613 in f875719

raise Exception("Incorrect type: NAME.")

I would expect something like:

    if (not isinstance(name, str)):
        raise TypeError("Argument 'name' to savemsh should be of type str")

As I understand it, the generic Exception class is only intended as a base class for exceptions and shouldn't be used directly.

Python is case sensitive so the use of NAME here also led to some confusion for me.

[dengwirda]

Well okay, fair enough --- I can see that one could use the various TypeError, ValueError, etc throughout. Is there a functional reason to prefer this though, is there an issue with try..catch?

NAME is only present in the error string, not in the code, so I'm not sure what the case-sensitive issue you're referring to here is.

[xylar]

Well okay, fair enough --- I can see that one could use the various TypeError, ValueError, etc throughout. Is there a functional reason to prefer this though, is there an issue with try..catch?

Yes, one major problem with using Exception as a general practice is that catching Exception is so general that it also catches things like syntax errors in the code block within the try and KeyboardInterrupt, which is what gets raised when you use Ctrl-C.

NAME is only present in the error string, not in the code, so I'm not sure what the case-sensitive issue you're referring to here is.

When I see the error, I search for "NAME" in the code and don't find it. I am used to seeing python errors that use the variable names with the same case that they have in the code.

[dengwirda]

Ah, okay --- no problem. Catching things like KeyboardInterrupt seems an unnecessary horror, so I'll add a new "to-do list" issue to swap over to TypeError and friends.

I'm not keen to update some of the other formatting type aspects though --- there's a broader, multi-language style that I try to maintain across jigsaw in general, and some of these quirks are examples of that. For issues of maintainability, as well as my own sanity, many of the comment strings, data structure layouts, etc, etc are as common as possible across jigsaw's underlying C++ implementation as well as the various other language bindings.

[xylar]

I'm not keen to update some of the other formatting type aspects though --- there's a broader, multi-language style that I try to maintain across jigsaw in general, and some of these quirks are examples of that. For issues of maintainability, as well as my own sanity, many of the comment strings, data structure layouts, etc, etc are as common as possible across jigsaw's underlying C++ implementation as well as the various other language bindings.

Okay, do as you see fit. I only will reiterate that Incorrect type: NAME. was not a helpful message for me. I had to read the code to figure out what it meant.

[dengwirda]

I swapped from Exception to the various TypeError, ValueError and friends in da9e256 which should hopefully clean up the try...catch issues here.

[xylar]

I appreciate that.

[dengwirda]

Updated to TypeError, ValueError and friends in #17.