Don't panic when parsing invalid Url to Uri #1399
Conversation
Instead propagate this parsing issue up to the calling function as a Result. See seanmonstar#668
|
Can one of the maintainers have a look here? This is causing some issues in a downstream project. lycheeverse/lychee#483 |
|
@seanmonstar any chance you could take a look at this PR? This is impacting some downstream projects that are breaking because of a library-caused panic. |
|
Hi - I'd like to politely check in on this PR (@seanmonstar). My downstream project is also affected by this. Trying to help out, I did a code review pass on this and it looks reasonable. A unit test that exercises a bad URI path would be a nice addition, to make sure this doesn't regress. |
|
Is there anything else that needs to be done before this can be merged? There still seem to be some failing tests and the branch is out-of-date. Any chance this can be fixed and merged? I also have this problem in my project, as invalid URLs panick and abort the whole program instead of just returning the error that can be handled. |
|
I just opened a new PR to revive these changes: #2040 |
Instead propagate this parsing issue up to the calling function as a Result. See #668 Original PR: #1399 Co-authored-by: Matthias <[email protected]>
|
Merged via #2040 |
Instead propagate this parsing issue up to the calling function as a Result. See seanmonstar#668 Original PR: seanmonstar#1399 Co-authored-by: Matthias <[email protected]>
This provides a way to handle the parsing error up the call stack instead of panicking.
See #668.
This change should not impact the public API as
Pendingstill gets returned fromexecute_request.@timvisee fyi