Yesterday, in a meeting with project stakeholders and a dev was demoing his software when an un-handled exception occurred, causing the app to crash.

Dev: “Oh..that’s weird. Doesn’t do that on my machine. Better look at the log”
- Dev looks at the log and sees the exception was a divide by zero error.
Dev: “Ohhh…yea…the average price calculation, it’s a bug in the database.”
<I burst out laughing>
Me: “That’s funny.”
<Dev manager was not laughing>
DevMgr: “What’s funny about bugs in the database?”
Me: “Divide by zero exceptions are not an indication of a data error, it’s a bug in the code.”
Dev: “Uhh…how so? The price factor is zero, which comes from a table, so that’s a bug in the database”
Me: “Jim, will you have sales with a price factor of zero?”
StakeholderJim: “Yea, for add-on items that we’re not putting on sale. Hats, gloves, things like that.”
Dev: “Steve, did anyone tell you the factor could be zero?”
DBA-Steve: “Uh...no…just that the value couldn’t be null. You guys can put whatever you want.”
DevMgr: “So, how will you fix this bug?”
DBA-Steve: “Bug? …oh…um…I guess I could default the value to 1.”
Dev: “What if the user types in a zero? Can you switch it to a 1?”
Me: “Or you check the factor value before you try to divide. That will fix the exception and Steve won’t have to do anything.”
<awkward couple of seconds of silence>
DevMgr: “Lets wrap this up. Steve, go ahead and make the necessary database changes to make sure the factor is never zero.”
StakeholderJim: “That doesn’t sound right. Add-on items should never have a factor. A value of 1 could screw up the average.”
Dev: “Don’t worry, we’ll know the difference.”
<everyone seems happy and leaves the meeting>

I completely lost any sort of brain power to say anything after Dev said that. All the little voices kept saying were ‘WTF? WTF just happened? No really…W T F just happened!?’ over and over. I still have no idea on how to articulate to anyone with any sort of sense about what happened. Thanks DevRant for letting me rant.

I've been working on implementing a fairly large feature on a project at work--

**Sorry. I should rephrase that**

I've been *trying* to work on implementing a fairly large feature on a project at work.

It's slightly complicated because I'm not as "in the know" with the project as I should be. I get tossed around projects a lot as the only designer+developer so I've got my hands in a lot of buckets... Or git repos I should say... My source tree has a lot of tabs open and each project is run by someone with their own ideologies on how stuff should be done and laid out and what not. Basically jumping between these projects leaves you mildly capable on all of them but not amazing at any of individual one them--

--I digress.

There's a bug I've been trying to fix.
--Stupid simple bug, literally just a casting issue or something but there's so much data in this one object that it's taking a few solid minutes of concentration to figure out which variable is busting it all up. It shouldn't take long to fix...

But it has. It has taken 4 days.

FOUR. DAYS.

...To fix what is basically a null reference exception.

Every time I sit down to work on this bug real quick I get pulled away to do a wireframe or change a flow chart or diagram or colour or print styling.

Every. God. Damn. Time.
4 days. Soon to be 5.

My commits are real low at this point guys.

Please boss man, just let me code...

After 'Dev' deployed a service using Azure ServiceBus, a particular queue/client was receiving errors.

Dev: "Looking at the logs, client is getting faulted."
Me: 'What is the error being logged?'
Dev: 'Client is faulted'
Me: 'No, that is our error when the client is either unable to connect or there is an exception in the middle of sending a message. What is the exception from Azure?'
Dev: 'Client is faulted. That's it. I'm going to have to re-engineer the code to implement a retry policy.'
<OK, I smell someone cooking up some solution finding, so I dig into the logs a little further>
Me: "Looks like an invalid connection string. The actual exception being thrown and logged is from the Azure client connection string builder. The value cannot be null."
Dev: "No, I'm looking right at the connection string in the config. Looks fine."
Me: "Looks correct on your machine, but what is actually being deployed to the server?"
<I could tell he was getting agitated>
<Dev clicks around, about 10 min. later>
Dev: "Aha!..I found it. The connection string in the config on the main branch is wrong, in fact, the entry is missing."
<dev fixes, re-deploys, life is good, I document the error and the root cause>
Boss: "Great job Dev."

*sigh* ..go teamwork?

Why do programmers take so long in the shower?
They read the directions on the shampoo bottle and follow them to the letter:
Lather, rinse, and repeat.
If only shampoo used for-loops in their instructions...
while(hair.isDirty){
hair.wash();
hair.rinse ();
}
while(hair.isDirty() && !shampoo.isEmpty()){
hair.wash();
hair.rinse();
}
Come on man, we should still stop if we run out of shampoo even if the hair isn't 100% clean yet.
while(hair.isDirty() && !shampoo.isEmpty() && tap.waterStillHot()){
hair.wash();
hair.rinse();
}
This could go on forever, I mean the adding of special cases.

try {
while(hair.isDirty() && !shampoo.isEmpty() && tap.waterStillHot()){
hair.wash();
hair.rinse();
}}
catch(sexException) { self.f___(spouse); } // spouse showed in in mid-rinse
catch(deathException) { spouse.arrangeForBurial(self); } // user died while showering
More importantly, you also need to catch a hairNotFoundException in the event that the user is bald. Or more properly, wrap the whole thing in "if(hair != null)". You don't want bald users throwing an exception every time they shower.

-- From a reddit feed a while back.

I don’t know if I would call it a quirk of the language or serious abuse of it :P

But I managed to get a null ref exception when comparing a local int variable to an int parameter to the same function in C#.

Since a local or parameter of type in cannot be null and I compared the variables them self and dud not try to access any property on them (and no extension method or implicit case or similar) my first thought, along with all colleagues that chipped in to help, was that this should not be possible.

Turns out the method was called through reflection and in that part it injected null as the base object to call the method on.

Since local variables actually are referenced through the parent object this was what was causing the null ref.

That took some time to figure out.

If there's one thing I'd gladly kill with fire, then pass it over a steamy steamroller, then burn it a tank of hot fluoroantimonic acid, is every fucking Java library that returns null instead of throwing a meaningful exception.
Is it really that difficult for you to throw an exception anyway, then let ME figure out if I can ignore it or not?
Thanks to you, now I have to do super messy reflection things just to figure why did you return a null.
I'm not your fucking psychologist trying to pull your inner secrets. But I have to be, for the sake of stability of my app. Which already has its own mess of problems on its own.

Fuck C# for real, like why in the FUCK DO YOU NOT AT LEAST THROW A FUCKING EXCEPTION WHEN I TRY TO CONCENTRATE A STRING WITH NULL, I SPENT 40 MINUTES DEBUGGING THIS SHIT JESUS FUCK

Edit, note: I'm having classes that return null when they don't find something. Why is it so hard for the fucking compiler to at least warn me or some shit!!!!!!!!!!!!

Return null or throw exception, that's the question!

Spent 3 hours trying to debug why java threw null exception when user disconnects or connects to room id to chat. Guess where the fucking bug was

Writing code at work be like:

Hmm okay so if I call this facade looking for an order with a code, and the order can't be found, it will return null. Thank God this bit of code is documented...

Ten minutes later

Why is this not throwing an exception when I pass invalid parameters in...?

Two minutes later

Oh, so this never returns null. If the order isn't found, it returns an empty DTO. Fucking docs.

Seriously, the only thing worse than no documentation is documentation that lies. And that's all I get for my first project at the company, which I am having to do alone. Either no docs, or misleading docs.

Just askin:
If you have a method which returns a value from an array. What do you prefer in a case when the item is not found?
A)Throw an exception
B)return null
C)return a special value like a null object or some primitive type edge value like Integer.MIN_VALUE

One of the worst practices in programming is misusing exceptions to send messages.

This from the node manual for example:

> fsPromises.access(path[, mode])

> fsPromises.access('/etc/passwd', fs.constants.R_OK | fs.constants.W_OK)
> .then(() => console.log('can access'))
> .catch(() => console.error('cannot access'));

I keep seeing people doing this and it's exceptionally bad API design, excusing the pun.

This spec makes assumptions that not being able to access something is an error condition.

This is a mistaken assumption. It should return either true or false unless a genuine IO exception occurred.

It's using an exception to return a result. This is commonly seen with booleans and things that may or may not exist (using an exception instead of null or undefined).

If it returned a boolean then it would be up to me whether or not to throw an exception. They could also add a wrapper such as requireAccess for consistent error exceptions.

If I want to check that a file isn't accessible, for example for security then I need to wrap what would be a simple if statement with try catch all over the place. If I turn on my debugger and try to track any throw exception then they are false positives everywhere.

If I want to check ten files and only fail if none of them are accessible then again this function isn't suited.

I see this everywhere although it coming from a major library is a bit sad.

This may be because the underlying libraries are C which is a bit funky with error handling, there's at least a reason to sometimes squash errors and results together (IE, optimisation). I suspect the exception is being used because under the hood error codes are also used and it's trying to use throwing an exception to give the different codes but doesn't exist and bad permissions might not be an error condition or one requiring an exception.

Yet this is still the bane of my existence. Bad error handling everywhere including the other way around (things that should always be errors being warnings), in legacy code it's horrendous.