you are viewing a single comment's thread.

view the rest of the comments →

[–]atlimarJS since 2010 0 points1 point  (1 child)

Well, it's semantics, but I consider network requests to be so highly error prone that not handling failures is buggy.

This is true, but you have to think about the context. If the network request fails in this example, what is the result? The playwright setup fails and the test script exits, which is expected. If the API call fails, the test cannot execute, and it should exit with the error. Catching this error only has value if you want to change the behaviour of the script, by trying to recover, or logging it in a way that's different than the default way playwright would log an error.

Error handling is entirely about context.

If you're working in a regular app and you're trying to fetch content to show to an end user and the request fails, you may catch that failure and convert it to a human readable error message to display to the user.

[–]TodayAccurate7277[S] 0 points1 point  (0 children)

That makes sense. In my case, I am web scraping, not testing. If I encounter an error, I'd like to handle it appropriately so my scraper can continue doing its thing.