Hacker News Reader

Those defensive measures you describe are the kind of hacks that introduce more and more complexity.

Defensive programming is not fixing bugs with more features, quite the opposite: it is failing hard when a condition does not hold.

Yeah... The whole try/except "in case it throws" without an understanding of IF it should and WHY it might is a huge anti-pattern that creates more bugs down the line than it may potentially solve in the short-term.

If it shouldn't throw, don't try to catch... That is an unexpected failure that needs to be understood.

I get so irritated whenever this is brought up as an "additional security measure". Like, guys, we just found the source of the bug and put in some code to fix it. If it fails again it shows we haven't understood it completely and should take another look. Not just throw in a random try-catch where the outcome is that if it fails again it's just that some string won't be rendered in the application anymore or whatever. Could take months before anyone notices and we learn that something basic has been broken all along.

Thank you for standing up for confident programming! (We could make this a new term if we wanted to :D)

EDIT: Wait, maybe there's a better term than confident programming already... I would appreciate some input if someone sees this.

Wikipedia seems to call it "offensive programming": https://en.m.wikipedia.org/wiki/Defensive_programming

There is a third route. You can add a try catch and then throw a more detailed exception (or otherwise automatically surface the issue while not degrading the user experience) showing the context of what failed, then fo attempt to fix a poorly understood bug for which you may have an incomplete set of reproduction circumstances for.

The best solution is, as always, context and resource dependant.

When I was interning at IBM (~15 years ago now), I saw a bug report closed with "added catch for NullPointerException" as the solution. Something tells me that developer didn't really dig to the bottom of the issue...

Well it depends on where. For ex: If a request handler in your web server is throwing an exception, it's not a good design for the whole server to go down because you thought it was a bad pattern to catch any exception that handling one request might throw. The whole request should fail, return a 500 to the client, and log exception details for later examination, but shouldn't be allowed to disrupt the rest of the server.

Thing is, request handlers cross a boundary. Thus, you really should expect them to get malformed input. This means wrapping it in a try catch because 'input might be bad' is a pretty sane thing to do.

At the same time, you really should try to validate inputs. The idea being that most exceptions caught should be of the form 'Input was invalid'. Rather than 'function crashed'.

Well the parent seems to argue for at least only a very specific and limited catch. Perhaps the most common error is, say, invalid JSON. You wouldn't want to catch only the exception for that though. Maybe that's the most common, but who knows what other kind of subtle bugs might be in there. And the rule of thumb is that the web server process should never go down, no matter what kind of weird data you throw at it. That makes that indeed a case of catch everything, log it, and then move on to handle the next request.

Sorry, I probably wasn't very clear - I'm not arguing that a try/except MUST be very targeted.

> without an understanding of IF it should and WHY it might

rocqua explains it best - the API handler is an "input" to the overall system. That input may be "invalid" in that it fails to handle its own errors. In that case, you should catch a general exception rather than crashing. In this case, you know that it might raise an error, why it might raise an error, and that it's OK to ignore (well, log/alert/whatever.)

The situation I was responding to is very different - it's basically suggesting rather understand what the API you're invoking may be trying to tell you, just try/catch anything it throws and ignore it if you didn't expect it.

> Those defensive measures you describe are the kind of hacks that introduce more and more complexity.

On the other hand, a system where damage is prevented in some ways and assumed not to happen in others is already an overly complex construction of interacting systems. Switching to an invulnerability flag could simplify the system.

I think you're right that it would have been a better design if it weren't possible for the companion to die in the first place. But I also agree with the parent that they were right to find the actual cause of their assumptions being violated before deciding how to implement the fix.

> 2. They never checked if the companions went somewhere silly to warp them back to where they should be

In a modern open-worldish game, this is pretty nontrivial.

This can't be understated. Like, for this particular thing? Yeah, you could say "oh, they're out of range of the ship and that should never happen, warp them back." But you have to have them escape the zone first to know you should do that. And what's the most likely way to do that? Falling out of the world. Not climbing. So there's a good chance you'll miss it even if you thought about it!

This is exactly the sort of bug that anybody under the kind of bone-crunching compression you see in game development is gonna fix after they see it. "Don't start bandaging until you bleed."

Not sure why this is getting so aggressively downvoted. A coordinate sanity check on entities is trivial to do, and at the very least should be logged.

Its not just that, but why test quest failure for if the companion is dead, if in principle companions can't die? This is a typical case of game design where lower level engine systems like physics dictate behavior/cause bugs in higher level functionality like the quest system.

Game engines do everything every frame by default, and the game has to disable/enable stuff from happening, which leads to bugs like this. With a more functional approach instead of tweaking the engine state these bugs can be avoided.

> why test quest failure for if the companion is dead, if in principle companions can't die?

The game's hardest difficulty setting - "Supernova" - allows companions to die [1] (as well as a bunch of other changes that make the game tougher, not just stronger enemies)

[1] https://www.pcgamer.com/uk/which-the-outer-worlds-difficulty...

That entirely depends on how complex the set of valid and invalid coordinates is.

A very basic implementation would use a bounding box. This is done quite often in MMO type games to make sure players don't end up outside the map geometry somehow.

As I said it can be easy or hard depending on the complexity of deciding what is valid or invalid. Just because you can think of something very basic doesn’t actually make it applicable to the task at hand.

> I can't understand your support for failing to put in some defensive measures when they couldn't recreate a frequently reported bug

From the tweet series: "There were one or two cases before launch where this issue seemed to happen, but no one in QA ever managed to reproduce it and despite our best efforts we couldn't learn anything concrete about it"

Assuming this is true, before launch, it was NOT a frequently reported bug.

After launch, they dove in and figured out what was happening AND what triggered it.

Your complaint appears to be that they (1) had a bug, and (2) didn't resolve boundary checking in the production code. Given the number of "fall through the map" bugs in countless games, I assume #2 is, in fact, hard. Writing non-trivial code without bugs (to avoid #1) is also hard, based on...all the smart coders I've read.

Regardless of the source of the bugs, I'm cheering that they didn't just put in defensive measures and called it a day. To the point that defensive measures can be a source of bugs, consider how many "violent vibration" bugs we've seen in, say, Skyrim, Fallout, and GTA. (While I don't play, based on clips I've seen from GTA and Red Dead, those engine(s) spam duplicate entities when the boundary overlap is detected, where Skyrim/Fallout just vibrate and rattle). I find it very plausible that attempts to "warp" characters having positional bugs without understanding the source of those bugs will end up a source of new bugs.

Re: (2), see https://caseymuratori.com/blog_0005 to see exactly how difficult it may be

>Given the number of "fall through the map" bugs in countless games, I assume #2 is, in fact, hard.

Can’t gamedevs reinvent solidness and make underground/walls solid? Viscosity/density/archimedes?

There's lot of great ways to ensure your collision detection is perfect. Sadly none of them run at 60fps.

collision detection is pretty hard to do in real time. you can't just iterate through every single entity and check if it's intersecting every single triangle in the whole world and have an acceptable frame time.

They are (a solid surface), but game physics are somewhat fuzzy due to performance requirements. Some games teleport you back on top of the ground layer if you fall too deep.

The "rattling" in Skyrim/FO is not specific to those engines but seems to happen in all games that use Havok (e.g. all Source based games exhibit the same behavior when something gets stuck in something else).

RAGE/GTA/RDR2 are so insanely buggy games that a game developer probably can learn nothing from them, except how to not do it, and that no matter how broken your games are, you can still earn billions.

You are wrong, but not downvote worthy wrong. Lets put a artificial cube around the ship, that teleports npcs back to a safe start location (lets call it there bunk).

Now you created a whole zoo of new troubles, including a whole set of troubles you cant even predict, because you didnt know about them when you made this giant default behaviour case.

if (specific case){

} else (everything else that could ever happen, inlcuding all future edgcases){

// here be dragons

}

Examples? Leveldesigner adds elevator, that transports player and npc ocassionally outside of the teleport box.

Skybox entitys are npcs that live outside of the box- so space battle npcs, get telported to bunks..

etc. etc.

Handling the unknown - with any other paradigm then the fail early, fail loud - is the root of evil.

Judging how defensive programming worked out for PHP, I consider it an antipattern.