Hacker News Reader

Comment by jiggawatts | Hacker News Reader

The author is wrong, browser behaviour does change significantly in one major way: errors are not cached.

Or much more importantly, errors incorrectly returned with 200/OK success codes are cached, semi-permanently breaking your site.

If you've get helpdesk staff telling customers to "clear their browser cache", this is one common reason why this "works" as a fix.

Please, I beg you: stop being "nice". Stop catching exceptions and dropping them on the floor! Let them bubble up to the web framework pipeline so that an error code is sent.

Your CDN will thank you. Browser caches will thank you. Corporate proxy servers will thank you. Application monitoring tools will thank you. Load balancers will thank you.

I kid, I kid. None of those will send you thanks in an email. Instead, they'll work tirelessly in silence to deliver your application as intended, instead of holding on to transient errors for days on end and upsetting your users.

View on HN

Letting an uncaught exception error reach the user is generally bad. It risks exposing secrets / confidential information to the user and any returned client side secrets risk getting into intermediary caches. The biggest risk is the user input being returned in the response creating an XSS (cross site scripting) risk. This is a very common source of reflected XSS vulnerabilities. You should always catch exceptions like this so you can at the very least sanitize them for XSS. This is already built in to some frameworks. If you are using something that doesn't you need to do it yourself and it's probably easier to just strip it all in production, you just need to make sure you are still setting an appropriate status code.

I think it’s cute you think most developers let exceptions rise.

Most developers I notice just catch the error right away and make the function return something non-sensible like a 0 for a string value function.

Slightly better developers just let the exceptions bubble.

The rare breed looks at what exceptions are being thrown, decides which ones to handle at which stack level, and repackages them as needed when the error cannot be handled that deep in that stack due to a lack of context. Then they write framework-level exception handlers for errors that rise to the top because they cannot be corrected at a higher stack level to give users specific error messages with user-correctable actions without revealing anything sensitive. “Your image is too small, wanker.”

Just a reminder that you don’t need to be patronizing to get your point across. Calling someone “cute” is a bit much.

Ahhh the Visual Basic days of:

On Error Resume Next

In the first line of every function. It's tells the Interpreter:

"Shhhh, it's fine. Just ignore errors. Division by zero? No worries. It's Fiiiiine. Try to access inexistent index of an array? Who cares, it's Friday!"

Gotta love these though:

  catch {};

Pokemon!

Who said anything about letting exceptions reaching the users!?

The exception needs to bubble up to the request pipeline, which will set an integer error code, and then... redirect to a generic "sorry we broke" error page.

Showing the full exception stack trace and other sensitive bits and pieces is for local debug mode, not for production.

...and there should be a guid assigned to the problem, in the logs, and possibly visible to the end user.

The APM does that for you.

Open Telemetry, Application Insights, New Relic, etc… will all stamp the request with a unique id and associate any errors with it.

Also: search engines. I spent a good chunk of a month fixing an app initially developed with this mindset. Immense value delivered just by making things work as they should've from the beginning.

Reply on news.ycombinator.com