Skip to content

Get rid of the ctry! & cexpect! macros #860

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
jyn514 opened this issue Jun 28, 2020 · 3 comments
Closed

Get rid of the ctry! & cexpect! macros #860

jyn514 opened this issue Jun 28, 2020 · 3 comments
Labels
A-frontend Area: Web frontend C-technical-debt Category: This makes the code harder to read and modify, but has no impact on end users P-low Low priority issues S-blocked Status: marked as blocked ❌ on something else such as an RFC or other implementation work.

Comments

@jyn514
Copy link
Member

jyn514 commented Jun 28, 2020

Pretty sure we can literally just replace ctry! with ? now given that errors without an explicit status code are treated as 500s (or if we can't, could try and make it so that we can). That would allow changing cexpect! usage into .ok_or_else(|| err_msg(...))?.

Originally posted by @Kixiron and @Nemo157 in #858 (comment)
@jyn514 jyn514 added E-easy Effort: Should be easy to implement and would make a good first PR P-low Low priority issues A-frontend Area: Web frontend C-technical-debt Category: This makes the code harder to read and modify, but has no impact on end users labels Jun 28, 2020
@Nemo157
Copy link
Member

Nemo157 commented Aug 8, 2020

Ok, I just attempted this, and it's not trivial at the moment. IronError doesn't implement From to allow using ? with it since it smushes together application level HTTP error codes and underlying server errors into the same type. This should be doable after/as part of the transition to hyper as long as we don't make the same mistake with the design of our "Handler".

@jyn514 jyn514 added S-blocked Status: marked as blocked ❌ on something else such as an RFC or other implementation work. and removed E-easy Effort: Should be easy to implement and would make a good first PR labels Aug 8, 2020
@jyn514
Copy link
Member Author

jyn514 commented Sep 13, 2020 •
edited
Loading

An easy way to make this nicer is impl From<Nope> for IronError - it will still need map_err in a few places, but fewer of them and shorter. (found in #1045)

@jyn514 jyn514 mentioned this issue Sep 13, 2020
Merged
@syphar
Copy link
Member

syphar commented Jan 11, 2023

both macros are gone after the axum migration was finished.

@syphar syphar closed this as completed Jan 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-frontend Area: Web frontend C-technical-debt Category: This makes the code harder to read and modify, but has no impact on end users P-low Low priority issues S-blocked Status: marked as blocked ❌ on something else such as an RFC or other implementation work.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@Nemo157 @syphar @jyn514