Is it acceptable to escalate a software error to HTTP 500?

Question

Should an error 500 only be thrown by the web server, or is it acceptable for your program to throw one itself?

try {
  some bad code;
}
catch (Exception) {
  set_header_code(500);
  set_content_type('application/json');
  set_response_body(json_encode({'is_error': true, 'message': 'An unknown error occurred', 'request_id': $random_number}));
}

Is this an anti-pattern?

EDIT

In response to Robert Harvey's comments:

500 Internal Server Error -- The server encountered an unexpected condition which prevented it from fulfilling the request.

Wikipedia -- A generic error message, given when no more specific message is suitable. The general catch-all error when the server-side throws an exception.

I could use this pattern to validate a form:

if ($email_address === null || !is_valid_email($email_address)) {
  throw new Exception('You must supply a valid email address');
}

The server has encountered an unexpected condition which is preventing it from fulfilling the request, namely the email field is missing or invalid.

The code can then catch this error later, converting it into a nice error 500 page with some JSON data that duplicates the error.

Why would you need both error 500 and {is_error: true}? How about if you generate an error 500 and say {is_error: false}? What does that mean? Why not leave it as 200 OK with {is_error: true}?

In JavaScript:

if (http_response_code == 500) {
  // The server did not respond as expected
  // Do not try to parse the response body as JSON
  //   because there's no guarantee it contains JSON data
  // Display default error message
}
else if (http_response_code == 200) {
  response = parse_response_as_json();
  if (response.is_error) {
    display_error_message(response.message);
  }
  else {
    // process response
  }
}

Answer 1

For form validation errors, a 400 - Bad Request is probably more semantically correct.

From RFC 7231:

6.5.1.  400 Bad Request

   The 400 (Bad Request) status code indicates that the server cannot or
   will not process the request due to something that is perceived to be
   a client error (e.g., malformed request syntax, invalid request
   message framing, or deceptive request routing).

500 - Internal Server Error is generally used when (and normally interpreted by clients as) "Something bad happened on the server, I don't know what it is (but even if I did, I probably couldn't tell you), and I'm giving up. Sorry it didn't work out."

Of course, nothing prevents you from returning 200 OK, serving an error status in your JSON, and letting the client work it out.

The key here is that a bad email address isn't an exceptional condition. It's simply an input error.

That said, the response code returned by the web server is an implementation detail. The only code that should know about that is the code of the web server itself, and possibly any code that you write which interacts directly with the web server. The rest of your code should not have to ever concern itself with that.

Answer 2

Using the narrow definition from Wikipedia's article on web servers:

The term can refer to the entire system, or specifically to the software that accepts and supervises the HTTP requests.

(emphasis mine), means that the software that the web server calls outside of itself should not deliberately send error 500, or any other error in the 500 range.

Here's a description of the response code groups in simple language:

• 2XX: Program says: I followed your instructions as best as I could and here's your response, or a report of why I couldn't do exactly what you asked
• 3XX: Program or server says: I know what you're asking for, but instead of giving it to you, I'm going to tell you a different way of getting the response
• 4XX: Program or server says: I can't give you what you're looking for
• 4XX: Server says: I don't know what you're asking for. Your request was mangled in some way
• 5XX: Server says: Uh oh! Something really major went wrong. I'm really sorry I can't be more specific than that

Since you don't know how strict or tolerant every client is, you SHOULD use the narrow definition and let the web server send most errors. By definition, a program can't send an error 500 (indicating it's not in a working state) because it has to be in a working state to do so.

The server is in several layers and it's not appropriate for all of them to send any response code:

• Server hardware
• Operating system (such as Linux)
• Web server (such as Apache) - sets a response code for every request
• Programming language (such as PHP) - causes an error 500 if the code crashes or has an unhandled exception
• Website code - can override the default response code if the rules are too complex for the server to work out, e.g. error 404, redirect 302, etc.

For example, if your pages don't have a physical location but are generated dynamically, the server doesn't know whether it can serve it with a 200, or it doesn't exist and it should send a 404. There is no other option but to override the code from within your program. However, it is bad practice to send a 500, because your program hasn't crashed at that point. While your program is running, you always have options.

It's especially bad to send two errors that mean the same thing as you're breaking the DRY principle (Don't Repeat Yourself). Your program determined that the request was good, but the data was bad (or some other error). It should exit normally, with a 200 code, and an explanation within the response of what the error was, and what the client or user should do.

TL;DR:

Error 500: big crash. Don't use for small things!