@cm0002@lemmy.world to Programmer Humor@programming.dev • 9 days agoYes, But...lemmy.mlimagemessage-square78fedilinkarrow-up1765arrow-down19cross-posted to: programmerhumor@lemmy.ml
arrow-up1756arrow-down1imageYes, But...lemmy.ml@cm0002@lemmy.world to Programmer Humor@programming.dev • 9 days agomessage-square78fedilinkcross-posted to: programmerhumor@lemmy.ml
minus-square@madcaesar@lemmy.worldlinkfedilink12•9 days agoHere I am preferring 200, with success boolean / message string… Iike HTTP errors codes for real fuck up’s, if I see 500 somethings fucked in the app, otherwise a standardised json response body seems way easier
minus-square@fuzzzerd@programming.devlinkfedilinkEnglish21•9 days agoWhat about both? User supplies bad input? HTTP 400 with response body json describing the error in a standard format?
minus-squarebountygiver [any]linkfedilinkEnglish7•9 days agowhen you are too lazy to ask your request library to not throw exception on non-200 responses.
minus-square@dan@upvote.aulinkfedilink5•9 days agoThrowing exceptions is fine since errors are an exceptional circumstance (not expected during normal use of the app), and you probably want errors to follow a different code path so that they can be logged, alerts triggered if needed, etc.
Here I am preferring 200, with success boolean / message string…
Iike HTTP errors codes for real fuck up’s, if I see 500 somethings fucked in the app, otherwise a standardised json response body seems way easier
What about both? User supplies bad input? HTTP 400 with response body json describing the error in a standard format?
when you are too lazy to ask your request library to not throw exception on non-200 responses.
Throwing exceptions is fine since errors are an exceptional circumstance (not expected during normal use of the app), and you probably want errors to follow a different code path so that they can be logged, alerts triggered if needed, etc.