Thing is, request handlers cross a boundary. Thus, you really should expect them to get malformed input. This means wrapping it in a try catch because 'input might be bad' is a pretty sane thing to do.
At the same time, you really should try to validate inputs. The idea being that most exceptions caught should be of the form 'Input was invalid'. Rather than 'function crashed'.
Well the parent seems to argue for at least only a very specific and limited catch. Perhaps the most common error is, say, invalid JSON. You wouldn't want to catch only the exception for that though. Maybe that's the most common, but who knows what other kind of subtle bugs might be in there. And the rule of thumb is that the web server process should never go down, no matter what kind of weird data you throw at it. That makes that indeed a case of catch everything, log it, and then move on to handle the next request.
Sorry, I probably wasn't very clear - I'm not arguing that a try/except MUST be very targeted.
> without an understanding of IF it should and WHY it might
rocqua explains it best - the API handler is an "input" to the overall system. That input may be "invalid" in that it fails to handle its own errors. In that case, you should catch a general exception rather than crashing. In this case, you know that it might raise an error, why it might raise an error, and that it's OK to ignore (well, log/alert/whatever.)
The situation I was responding to is very different - it's basically suggesting rather understand what the API you're invoking may be trying to tell you, just try/catch anything it throws and ignore it if you didn't expect it.
At the same time, you really should try to validate inputs. The idea being that most exceptions caught should be of the form 'Input was invalid'. Rather than 'function crashed'.