https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #8 from Paul Sanders <p.sanders at alpinesoft dot co.uk> --- Thanks for your comments. I can see there are two sides to this. I was in the middle of composing the tract below. I'll include that anyway because it took me ages to type. There's a bit at the end about people who might get bitten if you do make this change, but a plausible alternative to crashing the program might be to (a) print "(null)", and (b) leave the badbit alone. I think I'd settle for that, I actually quite like the way the printf family behaves. My view of the badbit, BTW, is that it's not there to catch programming errors - it's there to report adverse events that come up at runtime (e.g. cannot open file). I expand on that below. ----- The code I posted was by way of example. I didn't realise at the time what was causing the behaviour I was observing - this whole thing came up on StackOverflow and you can see the thread here (please excuse me calling gcc 'naughty', I didn't have the full picture then): https://stackoverflow.com/questions/50696746/c-template-class-instance-issue I guess my point is that the way things are implemented currently is likely to lead to subtle, undetected bugs. Not everyone checks for errors properly, and not everyone (and that included me until just now) knows that if you want an iostream to throw exceptions you have to tell it so. Result? People innocently write code like that shown on in that thread and think they have done all they need to. But they haven't. So I see the current behaviour as being the worst of all worlds. After all, ostream would likely crash if the pointer was invalid, so what's so special about NULL? They are both programming errors, and not the sort of situation you want to have to write extra code to handle explicitly. Throwing an exception should be reserved for some external influence on the stream (such as a remote file becoming inaccessible due to a network error, say), which you *do* need to handle in your code. To put it another way, what are you going to do in your exception handler if you get a nullptr exception (whatever that is - is there even one?). Display "nullptr encountered, operation aborted" to the user and bail out? That's not going to impress your customer base. The reason I like bringing the program down is that it provides an opportunity to generate a stack trace and post it home somehow. But hopefully, the coding error is discovered before the code even gets out into the field, if you do this. [Additional note: I can see if you change the current behaviour you might get a bit of flak from people whose programs "used to work fine". Well, they didn't, and they should be grateful to you for alerting them to that fact.]
