Best Practices: how much detail to put in error messages

Lets say I am making a custom fixed-sized array type in Python. This array supports setting a range of values using a slice and an iterable.

a = Array("1234")
a[1:3] = "to"
a == Array("1to4")

Because the array is fixed in size, you cannot do what you can with lists where you set a slice using an iterable of larger or smaller size, which changes the size of the list; instead you should raise an exception.

a = Array("1234")
a[:] = "thisistoobig"  # ValueError

The question is, how much information should go in the exception’s error message? Should it include the value that caused the failure? Should it include only the length of the value? What about the length of slice you are trying to set?

The same question could be asked in general, what happens when you index out of bounds? Python’s error message for indexing a list out-of-bounds is "list index out of bounds" with no mention of the index value that caused the failure. Is there a general philosophy of “just use a debugger to find the failing value”? Is there some other consideration as to why it couldn’t or shouldn’t be more informative? Or is it just all over the place and there is no recommended best practice here, or in the main codebase?

Is there some other consideration as to why it couldn’t or shouldn’t be more informative?

For instance, a collection object might not want to leak information about its
contents in a log file.

Otherwise, precise information about what failed and how… helps.

a collection object might not want to leak information about its
contents

I’m not sure how this explains the current out-of-bounds indexing behavior on the built in types? Seems like that’s fairly pertinent information. As a parallel, AttributeError prints the failing attribute.

It might make sense if the index value was of an unknown type. The value might be large or have an expensive __repr__, which might be an issue if the user intends to catch these types of exceptions a lot. In the builtin’s case, it shouldn’t be a problem since it will be a subclass of int. You might run into issues if your subclass does something stupid in __repr__? Maybe that was the rationale? I would prefer more informative error messages on average than worrying about a small set of users doing something odd and shooting themselves in the foot.