It never really seemed like that to me, to be honest.
Any error that I have forgotten to handle is a bug, in the sense that it was a bug to have forgotten to handle the error in the first place. So the standard behavior of "treat every unhandled exception as a 500 response" is technically correct there. Upon consideration, some errors are actually so rare and/or catastrophic that I don't even have to worry about handling them because I wouldn't do anything different anyway. For example, suppose I have a database-backed service that has no meaningful failover if the database is down, and it throws an exception whenever the database is down. There is no reason for me to have to handle that error.
There are other error cases where I have to stop handling the request but it isn't my fault. So if my service has an endpoint that expects a JSON POST body and the body doesn't even parse as JSON, maybe I need to handle that so it throws a 400 instead of a 500. But I could just wrap that exception with a custom class that my error handler generates a 400 response for, and then the rest of my code could just go on assuming that the JSON did parse and that it was valid.
Probably the closest equivalent would be if you had a forking web server where each request had its own thread, and you could effectively kill the thread with a response object at any time. It's not really a case of "using exceptions for flow control" or whatever; it's more a case of "this entire unit of execution is finished and can kill itself just as soon as it's done leaving a note".
Any error that I have forgotten to handle is a bug, in the sense that it was a bug to have forgotten to handle the error in the first place. So the standard behavior of "treat every unhandled exception as a 500 response" is technically correct there. Upon consideration, some errors are actually so rare and/or catastrophic that I don't even have to worry about handling them because I wouldn't do anything different anyway. For example, suppose I have a database-backed service that has no meaningful failover if the database is down, and it throws an exception whenever the database is down. There is no reason for me to have to handle that error.
There are other error cases where I have to stop handling the request but it isn't my fault. So if my service has an endpoint that expects a JSON POST body and the body doesn't even parse as JSON, maybe I need to handle that so it throws a 400 instead of a 500. But I could just wrap that exception with a custom class that my error handler generates a 400 response for, and then the rest of my code could just go on assuming that the JSON did parse and that it was valid.
Probably the closest equivalent would be if you had a forking web server where each request had its own thread, and you could effectively kill the thread with a response object at any time. It's not really a case of "using exceptions for flow control" or whatever; it's more a case of "this entire unit of execution is finished and can kill itself just as soon as it's done leaving a note".