Phase 4 error handling

[mewilker]

Explanation

The Phase 4 tests introduce a test to students that makes sure that when a SQLException or more appropriately a DataAcessException is thrown due to the inability to get a connection, the error is handled as an "Internal Server Error". While this test is good and teaches students to handle unforeseen errors appropriately, it references the Phase 3 spec. While it would be nice if this was implemented and Phase 3 and carried over seamlessly in Phase 4, my experience is that most students don't begin to error codes until this Phase 4.

If their code works properly in Phase 3, they never really run into the 500 response. Sure, it would be nice for debugging if they caught their null pointer exceptions and sent a 500 back, but most of them don't do that. They typically either A) let Javalin execute its default behavior (catch the exception and print it to the console) or B) have an else statement for one of their status codes (like the 400 for bad request) and have that returned. They may struggle with this through Phase 3, but ultimately, they pass the StandardAPITests without ever having to worry about the 500 at the bottom of each of our endpoint tables.

Then comes along Phase 4. A lot of students seem confused about what the Database Error Handling Test means and spend some time trying to figure out what the test is asking for. Some of them spend some time trying to figure out what they are serializing and what exactly the test wants. Now I believe @Maillman's PR to change the tests should help clarify this (found here: softwareconstruction240/chess#49) but I think there also needs to be a reference to the Phase 3 spec in the Phase 4 one. This is so students can understand where this expectation comes from. Rather than determine our expectations from the test, they are reminded in the spec how to handle database errors.

Changes

This PR adds a small new section to the spec. The paragraph explains the response that is supposed to happen when connections occur. It also links to the Phase 3 spec, so they can be reminded of the format we expect.

When to Merge:

This PR could be merged as soon as the professors deem it appropriate, however since Phase 4 has already passed, it may be a good idea to wait for Winter 2026 to end.

[leesjensen]

Would it be better to implement Issue 295 before we add more DB testing code. With #295 implemented it would be very easy to do failure testing.