#Throwing/catching an error in case of 500 response?

1 messages · Page 1 of 1 (latest)

rustic elbow
#

1.) Should a 500 response cause an error?
2.) Should I catch it, if I can recover from it. Background is that the application spawns multiple threads. In case of an error the whole application dies because of 1 error

pastel talonBOT
#

<@&987246399047479336> please have a look, thanks.

rustic elbow
#

Well I can not really recover from it but I could stop processing the 1 set of data, which would kill the whole application. Therefor everything else could still work.

trim robin
#

what do you mean by set of data

#

is this like a web scraper type thing?

rustic elbow
#

Well the application fetches data from an API and tries to send them to another server. If the server I send it to responds with a 500 ( because the input data/json was corrupt/miss matching) my application throws an error and crashes. However only 1 dataset is corrupted (consistently) everything else that gets fetches is fine

trim robin
#

so is his issue that you don't know when it fails?

#

like you catch and silently throw away the error?

#

or that you don't know to reprocess / try again later?

rustic elbow
#

I Basically kill the thread instead by throwing a runtime exception

#

It gets retried later on tho

trim robin
#

that sounds fine - seems like you just need to set the thread(s) uncaught exception handler to log it in a way you can be aware of

#

like with sentry or whatever

#

silently failing is an issue - failing loudly but letting parallel tasks continue is fine

#

what was your old coworker's issue with that?

rustic elbow
#

Catching error = bad

trim robin
#

well, if catching error = you don't find out about error until later

rustic elbow
#

I had more of an issue with 500 = program crash

#

Because I feel like a 500 could always occur for various reasons

trim robin
#

just assume it happens 20% of the time because god hates you

#

plan accordingly

rustic elbow
#

@wanton atlas

#

Anyway I really need to go sleep. Thanks for the response tho.

silent sphinx
#

you should always anticipate any external service to fail to respond or to error out

#

your application definitely shouldn't crash in this case

#

a lot of thinga can happen

wanton atlas
#

Hi, I'm the old coworker. Let me add some context:

  • The whole thing is a microservice that polls Files from an external REST-Api and redirects them to the public REST-Api of our other product.
  • If the code works like I left it, the application should not crash due to errors, except if they occur in the initialization logic.
  • File imports are grouped parallel task, that each belong to a BO, which contains some data.
  • If one task fails, the others should continue.

My argument is as follows: If you don't expect something to go wrong, throw an error, don't recover from it, propagate it to the highest level possible, and then log it. If you expect something to go wrong, throw an Exception instead. Catch it, recover from it, and also log it.

If you thought that something might not happen, like getting malformed JSON from your own api, which uses a well tested library, and you throw an error, but it later turns out, that this happened and might happen again: Never catch the error, but throw an Exception instead.

Thanks for coming to my TED talk.

trim robin
#

Never catch the error, but throw an Exception instead.

#

that final exception

#

what are the consequences of it happening?

#

it sounded like galiron was saying that there were parallel tasks

#

and if one of those tasks failed it would abort the others

#

so im confused still on what the actual behavior was

rustic elbow
#

this the error killed the whole application, making it restart and run into the same error again.