cm0002@lemmy.world to Programmer Humor@programming.dev · 1 month agoYes, But...lemmy.mlexternal-linkmessage-square78linkfedilinkarrow-up1764arrow-down19cross-posted to: programmerhumor@lemmy.ml
arrow-up1755arrow-down1external-linkYes, But...lemmy.mlcm0002@lemmy.world to Programmer Humor@programming.dev · 1 month agomessage-square78linkfedilinkcross-posted to: programmerhumor@lemmy.ml
minus-squarefuzzzerd@programming.devlinkfedilinkEnglisharrow-up21·1 month agoWhat about both? User supplies bad input? HTTP 400 with response body json describing the error in a standard format?
minus-squarebountygiver [any]@lemmy.mllinkfedilinkEnglisharrow-up7·1 month agowhen you are too lazy to ask your request library to not throw exception on non-200 responses.
minus-squaredan@upvote.aulinkfedilinkarrow-up5·1 month 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.
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.