Simplify ZeroVec/VarZeroVec error handling, consolidate ULEError type

[Manishearth]

Prerequisite of #1079

Hitting a ZeroVec error likely means that you fed ZeroVec invalid data, and the utility of the error type is limited. Instead of having a complex heirarchy of error types that compose and can retain all error data from the source, we use a simpler ULEError type that broadly categorizes errors and includes the relevant type info.

This makes writing the proc macro (#1079) much easier since it does not need to generate error types as well. Furthermore, it simplifies ZeroVec for end users.

A change that I did not make here but perhaps should is renaming ULEError to ZeroVecError; since the place most users will see this is from ZeroVec and VarZeroVec. Thoughts?

[jira-pull-request-webhook]

Notice: the branch changed across the force-push!

• utils/zerovec/src/varzerovec/borrowed.rs is different

View Diff Across Force-Push

~ Your Friendly Jira-GitHub PR Checker Bot

[sffc]

A change that I did not make here but perhaps should is renaming ULEError to ZeroVecError; since the place most users will see this is from ZeroVec and VarZeroVec. Thoughts?

Or zerovec::Error ? (This is a utility crate so we can follow Rust conventions more than ICU4X which targets other programming languages)

Are there any other errors we surface in the zerovec crate?

[sffc]

Thought: Should we add special parsing methods to PlainOldULE that are infallible?

[Manishearth]

We already have From<[u8; N]>, but it's pretty moot here since it's tricky to statically prove that a subslice is of a given length (until someone writes a slice<N1, N2> function)

[Manishearth]

No, there are no other errors. My understanding of the convention for not prefixing errors is that it's kinda outdated: It was an aspirational convention at 1.0 but people never really took to it because it quickly gets confusing.

[sffc]

Nit: If you name this ZeroVecError, please move it up to the top level instead of nesting it under ule

[Manishearth]

Done. I continued reexporting it from ule for the convenience of glob imports

[sffc]

No, there are no other errors. My understanding of the convention for not prefixing errors is that it's kinda outdated: It was an aspirational convention at 1.0 but people never really took to it because it quickly gets confusing.

I still find I prefer writing cratename::Error and having it "just work", such as when I write From impls for my own error type. I find that much easier than having to go to the docs and figure out what error name they used. I find that I very rarely need to use cratename::Error. But maybe application developers need that more than library developers.

[Manishearth]

Yeah in my experience app devs often need it more. It's a tricky tradeoff, but a core thing is that folks really dislike renaming imports (for whatever reason), and folks tend to avoid full paths for types.