You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a many scenarios where I have one Uri and want to change its path_and_query, but this doesn't seem possible without writing code that can yield at least two distinct errors.
This doesn't make sense; realistically, only one error can occur: that the path_and_query is invalid. Beyond that, the operation should be infallible.
Here's one approach that I tried:
// self.base_url is of type `Uri`pubfnrelative_uri(&self,path:&str) -> Result<Uri,XXX>{letmut parts = self.base_url.clone().into_parts();
parts.path_and_query = Some(path.try_into().unwrap());Uri::from_parts(parts).unwrap()}
Because there's two possible error types here (http::uri::InvalidUriParts or http::uri::InvalidUri), I need to have an enum error type for this function that can be either of both variants (or Box it, or wrap it in some common type).
This makes my API a mess because now callers need to handle two distinct error types (or a container of various types) for an operation that, realistically, can only fail in a single way (the path_and_query supplied is invalid).
I tried using the Builder pattern, but the type returned by hyper::Uri::scheme cannot passed to http::uri::Builder::scheme, so I end up with a bunch of failure branches again.
These three approaches could work around the issue:
Mutate an Uri and change its path_and_query, or
Create a new Uri using the Parts from another while changing only one part.
Allow creating a builder pre-populated with Parts from an existing Uri. This would allow re-writing the above example in a way that only one error needs to be handled.
The first one has been mentioned in the past and it seems its undesirable, so I'll just ignore it. The second is tricky to design with a clean API. The third is probably the simplest, since the builder can be initialized with the parts from the source Uri.
I have a many scenarios where I have one Uri and want to change its
path_and_query
, but this doesn't seem possible without writing code that can yield at least two distinct errors.This doesn't make sense; realistically, only one error can occur: that the path_and_query is invalid. Beyond that, the operation should be infallible.
Here's one approach that I tried:
Because there's two possible error types here (
http::uri::InvalidUriParts
orhttp::uri::InvalidUri
), I need to have an enum error type for this function that can be either of both variants (or Box it, or wrap it in some common type).This makes my API a mess because now callers need to handle two distinct error types (or a container of various types) for an operation that, realistically, can only fail in a single way (the
path_and_query
supplied is invalid).I tried using the
Builder
pattern, but the type returned byhyper::Uri::scheme
cannot passed tohttp::uri::Builder::scheme
, so I end up with a bunch of failure branches again.These three approaches could work around the issue:
Uri
and change itspath_and_query
, orUri
using theParts
from another while changing only one part.builder
pre-populated withParts
from an existing Uri. This would allow re-writing the above example in a way that only one error needs to be handled.The first one has been mentioned in the past and it seems its undesirable, so I'll just ignore it. The second is tricky to design with a clean API. The third is probably the simplest, since the builder can be initialized with the parts from the source
Uri
.I think something like this is quite viable:
This could then be used as:
Note that there's only one failure branch (and one error type) that needs to be handled.
Though, perhaps the following is as simple, useful and a bit more correct:
The text was updated successfully, but these errors were encountered: