[doc] Mention exceptions that can be raised by numpy.load upon corrup…

[serge-sans-paille]

…ted files

While fuzzing numpy.load through google/oss-fuzz#13001, I realized that some exceptions could be raised upon malformed .npy files but were not documented.

This patch documents those exceptions.

[mattip]

The style guilde mentions that

This section should be used judiciously, i.e., only for errors that are non-obvious or have a large chance of getting raised.

Typically would a user expect all possible values to be specified?

[serge-sans-paille]

I'd say low chance of being raised, and not obvious at all to understand them, which... doesn't help :-)

[seberg]

Thanks for improving loadtxt fuzzing there, that is neat.

If others disagree, happy to change my opinion, but I would also not document these: I tend to think most "bad input" style errors don't need documentation.

One argument: Documenting (to me) mostly makes sense if someone might want to write a try/except for them (or if correct input can raise for not extremely obscure reasons). But if that was the case here, we probably would have to wrap up those errors into a single IOError or CorruptedFile error to enable a try/except.

[serge-sans-paille]

@seberg I'd happily follow your advice there. It was looking borderline to me, but I thought I'd mention it and discuss the situation around a small patch.

[ngoldbaum]

I think I agree with Matti and Sebastian not to document these, since if these errors are triggered users should see these errors and it would be bad to mask them with an overzealous try/except clause.