Panic less and with better messages #281
Žádní posuzovatelé
Štítky
Bez štítků
A: API
A: Backend
A: Federation
A: Front-End
A: I18N
A: Meta
A: Security
Build
C: Bug
C: Discussion
C: Enhancement
C: Feature
Compatibility
Dependency
Design
Documentation
Good first issue
Help welcome
Mobile
Rendering
S: Blocked
S: Duplicate
S: Incomplete
S: Instance specific
S: Invalid
S: Needs Voting/Discussion
S: Ready for review
Suggestion
S: Voted on Loomio
S: Wontfix
Žádný milník
Žádný projekt
Žádní přiřazení uživatelé
2 účastníků
Oznámení
Termín dokončení
Žádný termín dokončení.
Závislosti
Nejsou nastaveny žádné závislosti.
Reference: Plume/Plume#281
Načítání…
Přidat tabulku
Odkázat v novém problému
K dispozici není žádný popis.
Odstranit větev „panic-refactor“
Smazání větve je trvalé. Přestože zrušená větev může existovat i po krátkou dobu, než bude skutečně odstraněna, NELZE ji většinou vrátit. Pokračovat?
Fix #21
Change most unwrap to expect, and don't panic when it can be avoided. Also return better http codes, i.e. 400 and 404, when appropriate.
The trait
rocker::request::FromParam
should probably be implemented for Post, Blog, Media, User and Tag. Then we wouldn't need to returnOption
s whenever an entity does not exist, and just let Rocket do the work for usThanks a lot!
And yes, implementing FromParams for these types would be a good idea.
After trying to, I guess it might not be possible, because we need a db connection, and I don't think there is a way to access managed state from from_param (it only takes a &RawStr as parameters). Nonetheless I'll ask on Matrix
Maybe with with
FromRequest
andRequest::get_param
then? But it may force us to duplicate parameters in the routes signatures…If we end up doing manual routing it may reduce code duplication a bit, but it will add a lot of complexity, and we won't be able to use rocket's code generation if we do so. I'll see what answer I get from Matrix, but what I said earlier might very well be a false good idea