have a single bad index error type?

[StefanKarpinski]

We currently have BoundsError (not exported), KeyError (exported) and with #24999 StringIndexError (exported), where I noted that it might be nice to have a single shared exception type for "bad indexing value", whether the thing you're indexing into is an array, a dict or a string.

[oscardssmith]

I think that BoundsError or IndexError would be the best names for this.

[JeffBezanson]

+1 for IndexError. My first thought was that the existing types make important distinctions, but the more I think about it I can't really back that up.

[vtjnash]

Currently we use BoundsError for places that use cartesian coordinates to order the elements, even if that container is not indexable. Examples include: getfield (with an integer index), out-of-bounds next on an AbstractDict née Associative, String, and, of course, Arrays.

We use a much larger assortment of types to describe bad index errors more descriptively. Those I could find include: String (UnicodeError: invalid character index), getfield (ERROR: type %s has no field %s), Array / getfield (UndefRefException), and of course AbstractDict née Associative (KeyError).

[nalimilan]

Indeed, the problem with unifying them is that for KeyError the set of valid indices would take much more space to print than for arrays, where a range is enough. It's also useful to have StringIndexError so that you know the problem is not that the index is out of bounds, but that it does not point to the start of a character. However, we could imagine unifying these under a common IndexError, with a field to distinguish between the different cases (giving for example the set of valid indices).

[vtjnash]

Adding or removing (or rearranging) information in the error hierarchy should be largely non-breaking to do later in v1.x. However, implementing custom dispatch via a field of IndexError feels like a Julia anti-pattern.

Do we have an issue for the other error types that overlap (and so we had to pick the one that felt "most specific") but might want to formalize? (e.g. #5234, #14273, #24699, #20402)

[StefanKarpinski]

I'm inclined to leave this alone for 1.0. Our error types are kind of arbitrary because our error handling is a bit loosey goosey (as is the fashion in dynamic languages), so until we have more structure in error handling in general, it's not going to make that much sense to try to systematize this.

[oscardssmith]

The counter argument is that adding error types can be done in a non breaking way, while removing them can not.

[vtjnash]

We now are using a lot of different error types, rather than unifying them