Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

In general, I agree. You don’t want silent failures. They’re awful and hard to reason about.

> By doing this, you're opening up for the possibility of showing a UI where the name is "". Is that really a valid state for the UI?

But as a user, if I get a white screen of death instead of your program saying “Hi, , you have 3 videos on your watchlist” I am going to flip out.

Programmers know this so they do that so that something irrelevant like my name doesn’t prevent me from actually streaming my movies.



This is a fine line. If you get a white screen of death you know something is wrong. If the first name is missing it may mean other things are missing and the app is in a bad state. That means the user could lose any work they try to do, which is a cardinal sin for an app to commit.

Context matters a lot. If it's Spotify and my music won't play is a lot different than I filled a form to send my rent check and it silently failed.


Totally agree, I think this is a good place for debug asserts which only throw during development, but fallback in prod builds.


> But as a user, if I get a white screen of death

No one suggests hard crashing the app in a way that makes the screen white. There are better ways. At least, send the error log to telemetry.


Well, what would be better is “Hi, you have…”, and that would require a conditional, not coalescing.


Exactly, something like a name missing shouldn't cause the app to completely error out for the user.


Yes it should, because hopefully errors are logged and reported and can be acted upon. Missing name doesn’t.


If the error isn’t repairable by the user, blocking them from using the app entirely is mean. If the error screen has a message telling the user where to go to set their name, that’s fine but annoying. If the error screen tells the user they can’t use the app until someone checks a dashboard and sees a large enough increase in errors to investigate, that’s a bigger problem.


This reads like a dogmatic view of someone who hasn’t worked on a project that’s a million plus lines of code where something is always going wrong, and crashing the entire program when that’s the case is simply unacceptable.


> something is always going wrong

I hate this sentence with a passion, yet it is so so true. Especially in distributed systems, gotta live with it.


Why not both?


That's how you get this feature: https://wiki.php.net/rfc/deprecate-bareword-strings.

tldr: undefined constants were treated as a string (+ a warning), so `$x = FOO` was `$x = "FOO"` + a warning if `FOO` was not a defined constant. Thankfully this feature was removed in PHP 8.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: