ISTM a less obscure fix would be for the daophot reader to catch this exception and raise some more specific parsing error exception.

@embray - There is already an InconsistentTableError for exactly that purpose, and in fact I went so far as to start writing a new issue saying that, in general, io.ascii readers should catch any errors internally and re-raise that. But then I wasn't sure and decided to let sleeping dogs lie (which as the owner of vigorous puppy is extremely important). This would be a big-ish fix and maybe it would be a good thing, but it would definitely involve a lot of try/except in the reader code. I actually thing the biggest benefit would be in being able to re-raise more useful errors for users.

In any case I think that given the precedent of catching some errors outside of InconsistentTableError, that this particular patch is OK for now.

Not sure if you were implying subclassing InconsistentTableError to be even more specific? That would be an idea as well.

Yeah I think that's fine. I think it's worth opening an issue for though. Maybe it could be done without too many try/excepts. Just in a few key places.

No, I wasn't implying anything of the like--I'm not expert enough on this code so I wasn't sure what existing exception class was most appropriate and so remained vague :) But having hierarchies of more explicit exceptions doesn't hurt so long as they're sensible :)

I've actually thought about catching this and raising an InconsistentTableError for it. While we can think about it for this specific case, I think it is better go with a broader approach:
We don't know know what readers we might have in the future and even in the existing readers there might be many edge cases like this one not yet discovered (e.g. we obviously did not think that the reader could possibly fail this way when we wrote it otherwise that error would have been caught).

Thus, I considered - instead of listing selected exceptions - to just catch all exceptions here. After all, we are guessing and if the guess process does not find a way to read the table it will say "they using guessing=False and see what goes wrong". However, I realized that I would probably not get that approach through your review, and thus opted for the middle ground. I think the most likely exceptions (those defined in io.ascii plus Value, Type and AttributeError) are now covered.

On second thought I want to advertise catching all exceptions. That's future proof, low maintenance and easy to understand.
If we want to catch certain exceptions and re-raise them as InconsistentTableError that's fine in case the reader is selected explicitly.

@hamogu - can you repost the relevant bits of this comment to #3346?

reposted and expanded in #3346.