BUG: Silencing errors of filled_value's casting in array_finalize in MaskedArray

[fengluoqiuwu]

Silencing errors related to the casting of fill_value in __array_finalize__ of MaskedArray, and using a default value if the original fill_value cannot be cast even with the method _check_fill_value.

While this approach may introduce some level of risk, it is reasonable to assume that if users set the fill_value themselves, they are aware that it may lead to undefined behavior with specific type casting. It is unfortunate that the casting of masked_array types is hindered simply because we assigned fill_value with the default value indirectly. This not only causes issues with methods that use dtype= directly, but also impedes any calls to ufunc that return a dtype different from the original dtype (since calls to the ufunc won't be applied to the stored fill_value), exacerbating the situation.

I believe this is the most effective way to address these issues, rather than designing a new ufunc for masked_array or marking whether the value was set by the user or not.
fixes #27165

[seberg]

@fengluoqiuwu two things here:

1. It would be nice to explain where the TypeError comes from. As a reviewer if I accept that catching the TypeError may be the best thing (probably also OverflowError?) the next thing will be to ask whether this is the right point.
2. We really can't merge even an obvious bug fix without a test and a test is also very helpful for reviewers.

[fengluoqiuwu]

It would be nice to explain where the TypeError comes from.

The TypeError is raised by the _check_fill_value method, which is converted various errors we want to catch, such as OverflowError, into TypeError.

We really can't merge even an obvious bug fix without a test and a test is also very helpful for reviewers.

I will add it later.

[seberg]

Thanks! Looking a bit closer, I suspect this is right and we could probably just do it. We don't know that the dtype matches, and we have to just fall back to the default when the "inherited" fill-value fails (this is part of __array_finalize__).

The reason I ask about where it comes from is that it may better to handle this in _check_fill_value itself. I see a similar branch in one place in compare where it catches (TypeError, ValueError).

In this case, I actually like if we could audit/clean up things a bit more. That probably means pushing this logic into _check_fill_value but adding a fallback=False argument to it.
(From which I hope two things. First, make it more obvious why the try/except is there. And second, make sure we add this logic in all places where it should be used and not just the one where it happened to be noticed.)

I think in most places probably we should fall back to None. But when a user does arr.fill_value = fill_value, I don't think we should (it is the users job to pass a reasonable fill value).

(It is unfortunate, that this was always weird, but the integer casting is now floating up these issues...)

[fengluoqiuwu]

I think in most places probably we should fall back to None.

I think using the default value is better. In the comment for _check_fill_value, it says that it will only return an ndarray, so the return value won’t be checked before use. Additionally, in _comparison, it uses the default value, which is the same situation as this one.