Panic less and with better messages #281
Sans évaluateur
Labels
Sans labels
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
Sans jalon
Sans projet
Sans assignation
2 participants
Notifications
Échéance
Aucune échéance n'a été définie.
Dépendances
Aucune dépendance définie.
Référence : Plume/Plume#281
Chargement…
Ajouter une table
Référencer dans un nouveau ticket
Sans contenu.
Supprimer la branche "panic-refactor"
La suppression d’une branche est permanente. Bien qu’une branche supprimée puisse temporairement subsister, elle NE PEUT PAS être facilement restaurée. Continuer ?
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