abort(418) is just quick and easy and gets the job done… even if I wasn’t the one reviewing the code it would throw up enough confusion to get attention.
It also works perfectly in case it accidentally gets pushed to production.
It doesn’t get the job done though… for anything non-trivial multiple errors can occur and if you just abort(418) then you don’t know which one it is. If you generate a real error message you can include some actually useful information. “This is some kind of error I triggered” is not anywhere near as useful as “The error is…”.
I mean, yea, I can pass a message with the 418 if I just have:
return "this error, blah", 418
I understand your point, and it's a good one. I really don't need to use 418, I just find it useful. I think the key is that when I see that 418 error, I know it's something I put in there at once.
I also think a naked 418 is a bit cleaner if it did end up on my production server, just because I'm not tipping my hat too much by returning anything about what's happening behind the scenes.
It could be a lot cleaner if I did everything by the book, but where I use this is just my hobby project, and I'm just going for doing as much as I can quickly, and the mental energy that goes into error handling could easily add very significant time. Again, you're not wrong, and it would be better if i clearly articulated these errors in the long run.
