Skip to content

Use specific Utf8Error for Message::{into_text, to_text}#535

Open
sehyunsix wants to merge 1 commit intosnapview:masterfrom
sehyunsix:fix/message-text-error-type
Open

Use specific Utf8Error for Message::{into_text, to_text}#535
sehyunsix wants to merge 1 commit intosnapview:masterfrom
sehyunsix:fix/message-text-error-type

Conversation

@sehyunsix
Copy link
Copy Markdown

Summary

  • Change Message::into_text() return type from Result<Utf8Bytes> to Result<Utf8Bytes, Utf8Error>
  • Change Message::to_text() return type from Result<&str> to Result<&str, Utf8Error>
  • These methods can only produce UTF-8 errors, so this aligns them with Frame::into_text() and Frame::to_text() which already use specific error types

Closes #438

Notes

This is a breaking change for callers that explicitly annotate the error type as tungstenite::Error. However, callers using ? in functions returning tungstenite::Result will continue to work since From<Utf8Error> for tungstenite::Error is already implemented.

Test plan

  • cargo check passes
  • All 43 unit tests pass
  • All 12 integration tests pass
  • All 4 doc-tests pass

🤖 Generated with Claude Code

The `into_text` and `to_text` methods on `Message` can only produce
UTF-8 errors, so return `std::str::Utf8Error` instead of the generic
`tungstenite::Error`. This aligns with `Frame::into_text` and
`Frame::to_text` which already use specific error types.

Closes snapview#438

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Copy link
Copy Markdown
Member

@daniel-abramov daniel-abramov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree it would be better to have some consistency in the error types.

I wonder if we could simply change the type of Error::Utf8(String) to Error::Utf8(Utf8Error). To my memory, the last change in this direction was done in 255aaa2. Perhaps we could just use Utf8Error instead? That would unify the error's return type across the crate. I think we use our own Result<X, Error> pretty much everywhere in the public API, except probably in parts of Frame (which is arguably a bit lower-level).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Message::{into_text,to_text} could use a more specific error type

2 participants