Facts.

Preach!

This we want.

“Nobody cares what went wrong, buddy.”

Go hug a cactus and tell a doctor that it hurts without telling him that you were hugging a fucking cactus.

Every time I did not use phpMyAdmin for more then 10 minutes and no way to work around it... 😬

It's not even entirely about trying to fix it, it's more like motherfuckers want to know whats actually up. I mean things like "does switching my device cus its a clientside thing work now?" can't be answered by this tiresome not-even-funny type of shit.

"A problem that should not have occurred has occurred" is an actual error message I have gotten in a Microsoft product.

I feel your pain man

Even an error code is better than nothing! I mean seriously, at least I can google that shit and see what other people have tried with that code

Yes!!! I was just telling my co-worker today that we needed more detailed error messages for the end user!

@hugh-mungus Just contracted AIDS reading that.

End users don't need detailed messages. They need an explanation of what happened.

If it's a 500, say the server shat itself;
403, not allowed to Access
404.. etc

End users shouldn't fix stuff. We do that.

@CptMeatball The point is if you rely on the user to report such errors, telling them “Oopsies!” without at least an error code won’t help yourself in identifying the problem.

@Japorized if you rely on your users to report errors, you're doing it wrong. Error reporting should be part of the platform. ;)

If you can show an "Oopsie"; you can fire an event that tells the admin there has been an oopsie.

@CptMeatball That is correct, on the right setup. Plus, it might not be something that we made, but by someone before us, who uses bad practices.

It's fake error messages.

I think sometimes error pages can expose "too much" of the architecture and it would mean that the site is more prone to be hacked.

So, I'd take an approach of a comprehensive error page, and if it's a serious one, do something like Google that shows encrypted error data to be sent to them.

I don't know, maybe my logic's flawed xD

Those kind of errors(customErrors in Asp.net) are designed for the end user, the reason is of no importance to them. You should get the stack trace/more details if you're hosting the site on the same machine that's trying to access it.

Hey Apple started it....

@Torbuntu "here try and Google this number to fix your issue. good luck."

@lavandysh Exactly, and that's Alan awesome approach for consumer-grade software. Because if you know your public will be "more than average" user, you can bail out with showing all the error stacktrace (supposing your software it's open too, otherwise...well, cryptic error codes are all you have left xD)

WHUPTEY DOOO!