feat: add try_field() to Schema

[waynexia]

Which issue does this PR close?

Closes #.

Rationale for this change

Schema::field() would panic when the index is out of bounds. This patch adds a safer method try_field() that would perform the bound check.

What changes are included in this PR?

A new method try_field() on Schema

Are there any user-facing changes?

[tustvold]

I'm honestly not sure about the need for this, given schema.try_field(i) is not appreciably less verbose than schema.fields().get(i) which also has the advantage of returning FieldRef

[waynexia]

I'm honestly not sure about the need for this, given schema.try_field(i) is not appreciably less verbose than schema.fields().get(i) which also has the advantage of returning FieldRef

I thought the current field() was kind of an "unsafe" function, and maybe field_unchecked() is more suitable. It's easy to find and call this method. But panicking here would be hard to debug as the panic info is just an out-of-bounds. Given it's a long-exist public API I add the new try_field() with some hint in field() so we don't break the public interface. I'd like to propose deprecating and removing/marking it unsafe field() as the next step. As you said users can always schema.fields()[i], but we will not provide an easy-to-called unsafe API.

[tustvold]

I thought the current field() was kind of an "unsafe" function

I think I would prefer to keep things as they are, I don't see an issue with panicking when an invariant is violated, especially as you get a helpful backtrace to the point of issue. I personally don't subscribe to the notion that panics are some evil thing to be avoided, they're just exceptions and they avoid literring code with unnecessary error handling verbosity.

Given there are simple alternatives for people who want to avoid panics for whatever ideological reasons, I think we're ok?