Consider design of error type(s)

[ids1024]

• What variants are useful to provide? What errors might a consumer of the library want to actually handle?
• Some error variants may only apply to certain methods. Should the same error type be used everywhere, or might it be helpful to have more than one?
• The x11 code currently has a swbuf_err helper method. Any helpers like this should be in error.rs and used in other backends where it's useful.

[i509VCB]

UnsupportedDisplayPlatform and UnsupportedWindowPlatform arguably don't need human readable name fields as the Display implementation could describe those errors in a human readable form.

[notgull]

• What variants are useful to provide? What errors might a consumer of the library want to actually handle?

I think we should only really consider user-caused errors, plus a backend error. So we should have things like integer overflow, display mismatch, and calling out of sequence.

• Some error variants may only apply to certain methods. Should the same error type be used everywhere, or might it be helpful to have more than one?

We should use the same for simplicity's sake, since they all need backend errors anyhow.

• The x11 code currently has a swbuf_err helper method. Any helpers like this should be in error.rs and used in other backends where it's useful.

I would support this.

Also, do we publicly expose the underlying enum type, or do we wrap it so that the actual enum is private, allowing us to change it if we need to?

[ids1024]

Also, do we publicly expose the underlying enum type, or do we wrap it so that the actual enum is private, allowing us to change it if we need to?

It should at least be a #[non_exhaustive] enum, anyway.

Matching on the enum is useful if the caller wants to handle specific errors. Are there errors a caller is likely to want to handle? Loss of connection to the display server might be something one would want to handle. There's been some work in Wayland in allowing applications to reconnect if a compositor crashes and restarts.

For backend related things it's only useful to the extent winit exposes the same kind of errors though (assuming softbuffer is used with winit). I haven't actually looked into how winit's error handling work's too much.