I’ve been making some silly mistakes lately.
Post your recent mistakes in this thread, and how long it took you to fix it.
I’ll start:
hashMap.get(myString) = myObject
hashMap.get("" + myString) = null
Took me almost an hour!
boolean filtered = filter.apply(this, cy, cy, h);
camera.position.set(cameraIY, cameraIY, 0.0f);
Both last week. Both took more than half an hour. And both could have been spotted much earlier if my variable naming decisions would not deny the capabilities of IntelliJ’s code introspection (“parameter ‘x’ is named ‘y’, are you crazy or just short on caffein?”).
fbPostEffects = new FrameBuffer(Format.RGBA8888,this.sw,this.sh, false);
fbPostEffects.begin();
...
fboPostEffects.end();
renderTexture = fboPostEffects.getColorBufferTexture();
fboPostEffects.dispose();
Yesterday I created a FrameBuffer for adding some shader effects and disposed it before using it. Spent about 45 minutes wondering why my screen was black.
int absoluteWidth = (int) (o.getWidthScale() * image.getWidth() * scaleWidth);
int absoluteHeight = (int) (o.getWidthScale() * image.getWidth() * scaleWidth);
Can you spot the mistake?
Oh, the joys of copypasting while forgetting to change what you copypasted.
God yes. So fun.
That only breaks if myString is null, and putting null keys in your maps is… questionable, usually 
Hmm, good point as I think about this more…
I should probably check if the string is null anywhere, that could cause a lot more trouble.
Really the empty string in the OP is a second string added to myString, its finding X file in Y folder. For the root it supposed to be empty (""). Putting myString in by itself and then trying to find plus the empty folder string later was the problem… Idk why checking for the folder being empty or not, then just searching for the myString fixed it. (So maybe myString isnt null)
Doing a small side project with Direct State Access (DSA) in “modern” GL 4.5. About an hour of my life I won’t get back… :
Am making a tower defense game, and I decided to make the turrets fire to the nearest point in the path of enemies. Then I also wanted to do optimized code, that is, the nearest point will only be computed on the creation of the turret and not with every projectile created.
if (nearestPathPoint == null)
{
nearestPathPoint = path.get(0);
for (Vector2 pt : path)
if (pt.distanceSquared(this.position) < nearestPathPoint.distanceSquared(this.position))
nearestPathPoint = pt;
}
// Now fire projectile towards nearestPathPoint after timer
But when creating the turrets, all turrets are firing towards same point. Then after an hour I realized, that I accidentally declared nearestPathPoint as static when it shouldn’t be. Precious amount of time in LudumDare JAM.
That’s why I set syntax colouring up so that static vars and methods appear in a completely different colour
Cas
While learning Vulkan I checked every result with assertions. This line of code compiled successfully:
/* Create the vertex shader module */
VkResult result = vkCreateShaderModule(device, &vertexCreateInfo, nullptr, &shaderModules[0]);
assert(result == VK_SUCCESS);
/* Create the fragment shader module */
result = vkCreateShaderModule(device, &vertexCreateInfo, nullptr, &shaderModules[1]);
assert(result == VK_SUCCESS);
When trying to create the graphics pipeline, the validation layers stated, that there’s no entry point named “main” in the fragment shader.
Double checked it and compiled the fragment shader to SPIR-V again. Same error message… took me some time to realize the mistake occured when creating the shader modules.
Did this one today:
BufferedImage tilesetImage = ImageIO.read(new File("test resources\tilesets\tileset.png"));
I’ve recently been working with JavaScript specifically NodeJS and I wrote something like this:
app.get("/", new function(req, res){
//do something
});
took me longer that I’m willing to admit to find the mistake 
Answer in case you’re as stuck as i was: [spoiler]removing the “new” in front of function fixes the code. The new makes the function run immediately as opposed to running when the user goes to the “/” route[/spoiler]
In case you don’t know, Node supports the async await pattern, so you could easily eliminate callback hell by using it with promises. Combined with Mongoose, I’d write
app.post('/login', async (req, res) =>
{
let user = await users.findOne({ "uid": req.body.uid }).exec();
// Do something with the user
});
The mistake possible here, is it you forget the await keyword, you’d get a Promise instead of the value which you’d expect. Took me an hour to find this.
Only since 7.6. And if you got callback hell you’re probably doing something wrong to begin with.
Not that there’s anything wrong with Promises (async/await) per se as long as you know what you’re doing.
You should avoid using the ‘new’ keyword entirely, it’s not necessary (unless some odd api requires it for some god forsaken reason).
The next mistake there is that if you do not wrap the await call in a try-catch (and handle it by possibly forwarding the error to next() - third parameter of the callback function) you’ll get an uncaught promise rejection error when the promise rejects, and that’ll cause Node to exit.
I know the need of using try catch to catch the errors, but not the next parameter. As far as I’m aware, the next parameter is only present in the middlewares in express.
function (req, res, next)
// call next to begin calling the middleware described next
But in case of route handlers, there is no next parameter as far as I know. Am I wrong somewhere?
Yes, you can use next, because the routing functions accept Middleware functions (and only Middleware functions) themselves. it’s just that most people leave out the next parameter, because it’s not needed in synchronous code (you could just as well throw an error there).
The number of times I stared at my screen, wondering why the position of the element I’ve just been working on is wrong, while I did everything right… A sure sign it’s time to shutdown your pc.