he has already been running his data for some time, so he has already validated it. That was why I didn't bother with the "die" or an "else" statement

Sounds like an exit interview! Or an epitaph. Or famous last words.

Giving the benefit of the doubt, maybe you are just saying that the program doesn't need specifically to die() on every exception. True, but die() is just one possible course of action after you check the return values of just about every operation and handle the errors usefully (gracefully being a distant second priority). If your program needs to read a directory or open a file, but it can't because the path doesn't exist, that's generally gonna affect the output. 99 times out of a hundred, if you were expecting to be able to open a file or directory and can't, you'll want an opportunity to stop and figure out what's up. That's why die() is so often used on file-opening operations.

You might also avoid the need to die() if you check for the existence of, or some attribute of, the file before attempting to open it, or in some way avoid the fatal error beforehand. It's fine to trap the error and then continue, but not checking is sloppy, and to the observer, a sign of a programmer who doesn't think things through.

Also not true that a 500 error is not useful over http. You can control what message is output by die(), and your webserver can have a handler to offer more info, or links out of there, or a game (see Chrome) or whatever. In most web applications it's far more problematic that the server pretends everything is OK so the user won't notice a problem, than if the application produces a useful message on error.