1) You can't do that in C/C++. At best you can catch only a subset of failures that way.

2) Any proposed design choice must be implemented with code, and that code can have bugs and crash. That is what happened here.

> You can't do that in C/C++

Well, first, the sync code might not need to be in C/C++. It could be in a sandboxed, safe language instead. Other browsers do that.

Or, at minimum, it could be in C/C++ but at least in a sandboxed side process, Chrome has the capabilities for that.

At some point, the results of what the side process did have to get communicated to the parent process. You can reduce the size of the channel, but you can't close it completely. Bugs happen. Bugs in never-executed code happen and tend to stick around longer.

> You can reduce the size of the channel, but you can't close it completely.

Of course, no one would argue otherwise. Every time you decide how much to reduce it, you define a tradeoff in terms of work vs. benefit.

> 2) It is a design choice on the Chrome team to fail fast and hard. It's better to get crash reports to our automated crash servers with diagnostics and stack traces than to have reports in the field of weird behavior with no way to debug.

It's a design choice that your product... which some people (myself included) pay money for, crash hard so that you can get better diagnostics? Sounds like misplaced priorities.

I disagree.

This sort of catchall and keep going error handling could leave your browser in a completely unknown state. It could start making bad requests, making the wrong requests, start leaking info, or more likely crash elsewhere but with a much less clean crash log.

When you don't know how to handle an error such that it bubbles all the way up to the top, often the best thing to do is crash. At least then you might get the logs that allow you to fix it and turn around the fix quickly and with confidence.

Crashes suck, but crashing and not knowing why sucks more.

This. I can't believe how many conversations I have had to have in my (short) career trying to convince people that catch(...) { /* ignore */ } is not an error-handling strategy, it is an error-ignoring strategy and opens you up for hilarious ROFLExploits, heisenbugs, and all manner of fun things. As a user an app crash sucks (I know that well, all apps I use have crashed before), but in order to fix it the developers generally need either a repro (almost no one provides these, at lest not reasonable ones, this case was an exception as the repro was trivial) or a crash-dump (less helpful as not all the info you need is always there). If you have a catch-all you have neither of these, at best you have vague reports that sometimes, when users do X, Y and Z and have been using your product for 18 hours then 'weird shit' starts happening. This is NOT the kind of bug you want to investigate if you value your sanity.

Sorry, I removed the point because I realized it wasn't relevant to this particular bug. This bug isn't a case of an assertion failing (which is the "crash hard" bit). It was just a logical failure. A bug.

(Incidentally, eliminating these kind of rarely executed branches is a bugaboo of mine. They frequently have problems.)

> It's a design choice that your product... which some people (myself included) pay money for

How do you pay for Chrome?

Purchase a Chromebook.

You pay for Chrome?

You should go interview with google's chrome team and bring this up, I'm sure it's something they hadn't thought of.

Among other things, that try..catch won't do anything for SIGSEGV(int * p = 0; * p = 1) and SIGFPE(1/0). You can handle the signals, or you could miss them like you did just now. That won't be a design issue but an implementation bug.

I think there's a disagreement about what is design and what is implementation.

If the code in the try block caused a segfault, would that have helped?

On windows you can catch segfaults with __try and __catch.

Trust me when I say you don't want to be writing code in a stack frame above someone else who catches and ignores exceptions using them.

There are actually some cases where windows will catch and discard segfaults if you have them in response to certain window messages. That bug was hard to track down, let me tell you.