Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It’s hard work printing nothing

tedunangst.com

Post reply on HN
Print view View original

51–60 of 79 posts

Re: It’s hard work printing nothing

#51

Post by voltagex_ »

ensiferum wrote: post #28
zeveb wrote: post #5

The more I see of what goes on under the covers, the more surprised I am that anything works at all. As an example, every gtk+ program I run spews thousands of errors to the console. Why? Are they bad? The programs seem to run anyway, never crashing more than one would expect. So … why the console spam?

I think not a single actual application is completely well formed. They all work on luck. Especially in the embedded world. Btw, my android just rebooted.

If you're interested, the next time your phone crashes like that, /proc/last_kmesg (or similar) may tell you the reason.

Whether or not this is acceptable for software and hardware to have gotten this unreliable is another question entirely.

Re: It’s hard work printing nothing

#52

Post by draw_down »

cperciva wrote: post #29

There’s an argument to be made that silly error messages are better than crashing browsers There's an argument, but it's a really lousy one. If you're passing NULL as a string to printf, your code is broken . A crash which results in someone tracking down and fixing the bug is far better than quietly doing something which is 100% guaranteed to be wrong .

Patience! :) The author briefly rebuts that viewpoint immediately after your quote ends. He is not actually making that argument.

Re: It’s hard work printing nothing

#53

Post by zubat »

lotharbot wrote: post #50
cperciva wrote: post #29

There’s an argument to be made that silly error messages are better than crashing browsers There's an argument, but it's a really lousy one. If you're passing NULL as a string to printf, your code is broken . A crash which results in someone tracking down and fixing the bug is far better than quietly doing something which is 100% guaranteed to be wrong .

> "A crash which results in someone tracking down and fixing the bug is far better than quietly doing something which is 100% guaranteed to be wrong." Not necessarily. Wrong is relative and can have either small or large costs, and crashing also has a cost to the user (and to the developers if they lose users.) As an example, I play a very old video game (Descent). One of the major problems with one of the modern sou…

There are two use cases there that end up with a conflict of interest: One is the UX of having a crash during an important play session(high stakes match) and the other is the developer ease of tracing and debugging errors, which favors crashing over letting erroneous behavior taint the whole system.

In practice this means that during development you want the game to fail fast and loudly so that the biggest bugs are taken care of, but gradually add features to fail more quietly later, e.g. by moving more errors into logs and traces.

Re: It’s hard work printing nothing

#54

Post by lotharbot »

zubat wrote: post #53
lotharbot wrote: post #50

Earlier quoted context omitted.

> "A crash which results in someone tracking down and fixing the bug is far better than quietly doing something which is 100% guaranteed to be wrong." Not necessarily. Wrong is relative and can have either small or large costs, and crashing also has a cost to the user (and to the developers if they lose users.) As an example, I play a very old video game (Descent). One of the major problems with one of the modern sou…

There are two use cases there that end up with a conflict of interest: One is the UX of having a crash during an important play session(high stakes match) and the other is the developer ease of tracing and debugging errors, which favors crashing over letting erroneous behavior taint the whole system. In practice this means that during development you want the game to fail fast and loudly so that the biggest bugs are…

Exactly right. Test builds can crash; production builds should log errors (and perhaps inform the user).

Re: It’s hard work printing nothing

#55

Post by tener »

r00fus wrote: post #47
ensiferum wrote: post #28

Earlier quoted context omitted.

I think not a single actual application is completely well formed. They all work on luck. Especially in the embedded world. Btw, my android just rebooted.

Wow. How do you put up with that kind of behavior from such a mission critical device like a phone?

You don't die when your phone reboots.

Re: It’s hard work printing nothing

#56

Post by tener »

qwertyuiop924 wrote: post #17
ryandrake wrote: post #10

Earlier quoted context omitted.

So? If they indicate a problem or potential problem, they should be fixed in the software. The fact that there is a "warning" message means that someone, somewhere thought it serious enough to write home about. If they don't indicate a potential problem, then why even print them? Think about how you're supposed to treat compiler warnings: You don't ignore them--they are there for a reason. Quite the opposite--you sho…

Read SQLite's FAQ on that. Given, most projects aren't as amazing as SQLite.

SQLite is indeed nothing short of amazing with regard to the testing they have.

Re: It’s hard work printing nothing

#57

Post by kelnos »

lotharbot wrote: post #50
cperciva wrote: post #29

There’s an argument to be made that silly error messages are better than crashing browsers There's an argument, but it's a really lousy one. If you're passing NULL as a string to printf, your code is broken . A crash which results in someone tracking down and fixing the bug is far better than quietly doing something which is 100% guaranteed to be wrong .

> "A crash which results in someone tracking down and fixing the bug is far better than quietly doing something which is 100% guaranteed to be wrong." Not necessarily. Wrong is relative and can have either small or large costs, and crashing also has a cost to the user (and to the developers if they lose users.) As an example, I play a very old video game (Descent). One of the major problems with one of the modern sou…

That's looking at it the wrong way. The bug is not that it received a malformed packet: any network-aware program must expect to receive bad data and avoid crashing or other undesirable behavior when receiving bad data.

Sure, the player's software on the other end should not have sent the malformed packet, but crashing on bad untrusted input is a bug of its own, and I'd say a worse one.

(And who knows, maybe the malformed packet wasn't caused by a bug on the other side, but by something malicious, or perhaps some sort of network-caused data corruption.)

Re: It’s hard work printing nothing

#58

Post by icebraining »

dkarapetyan wrote: post #43
icebraining wrote: post #34

Earlier quoted context omitted.

That's rich coming from PHK, whose software requires a full C compiler as a runtime dependency. The reason Firefox pulls libtiff is simply because it uses a generic image manipulation library (libgdk-pixbuf), which in my system it's also used by many other applications - which do require TIFF support. I guess if you have a desktop with only FF installed that may be a waste, but how many people really have FF and not…

That's a very sensible requirement. It says in the docs exactly what they use it for. Not like they put in a bunch of other dependencies and some 3rd degree dependency pulled in a C compiler.

The C compiler in question pulls in a bunch of libraries for dealing with math problems (libgmp, libisl, libmpc, libmpfr) and zlib. Does their config language need support for "integer points bounded by linear constraints"? And why are they pulling zlib, when they also bundle it?

I don't see the difference. Instead of including a specific compiler for their needs, they are bazaar-ing a full generic C compiler (along with irrelevant libraries) just like Mozilla is doing with a generic image manipulation library, which pulls libtiff since many packages that also use it need TIFF support.

Re: It’s hard work printing nothing

#60

Post by tsukikage »

ensiferum wrote: post #28
zeveb wrote: post #5

The more I see of what goes on under the covers, the more surprised I am that anything works at all. As an example, every gtk+ program I run spews thousands of errors to the console. Why? Are they bad? The programs seem to run anyway, never crashing more than one would expect. So … why the console spam?

I think not a single actual application is completely well formed. They all work on luck. Especially in the embedded world. Btw, my android just rebooted.

"Complex systems usually operate in failure mode", (c) John Gall
Post reply on HN