Why, oh why, do we return empty things on error

[Zecc]

@sloosecannon said in Why, oh why, do we return empty things on error:

If I was a hiring manager, and got a sample like that... it would be..... hard to justify hiring someone based only on that sample. Especially if your reaction when prompted about code style questions is similar to how you react on this forum.

@Zenith said in Why, oh why, do we return empty things on error:

But posting a picture of somebody pouring bleach in their eyes is totally kosher.

TDWTF is a job interview? I'd like to retract from some of my previous posts.

[Zenith]

@sloosecannon said in Why, oh why, do we return empty things on error:

You're claiming bugs don't exist in your codebase.. or at least that's how I read that sentence. That's swampy levels of delusion. You do write bugs, just like everyone else

No, not really. I actually reduced downtime by several orders of magnitude on the last project I had real influence on. Because I do what's called "defensive programming," along with other lost arts like testing and documentation. It's amazing what you don't deal with when you program more stuff yourself than just plugging into automagic framework templates. My code was so safe I didn't use a debugger for the first decade of my career because I didn't have to.

Not sure what the last bug I wrote was. Technically, the one I referred to earlier I just chose not to fix. At home I've been struggling with a few Win32 problems (native scrollbars and autosizing - lots of fun there) but those aren't published so they're more WIP than bug. I guess the time I didn't realize one class in the application was saving a single blank space instead of zero or null. But that was years and years ago.

@sloosecannon said in Why, oh why, do we return empty things on error:

it means that your code can only be worked on by you, and if you ever leave, they'll be stuck with something that nobody else can easily fix.

Oh no, they'll have to treat me like a person so I don't leave! The horror!

[Zenith]

@Zecc said in Why, oh why, do we return empty things on error:

TDWTF is a job interview? I'd like to retract from some of my previous posts.

I'm not allowed to be assertive or confident.

If @sloosecannon thinks I fly into a frothing rage in interviews, he's off his rocker. First of all, it's well-documented that I have trouble getting interviews. I can't run around naked screaming PASCAL CASING IS THE ONE TRUE GOD if there's no interview. Secondly, it's well-documented that I get mostly stupid questions in interviews (either spirit animal questions or "hur dur what's the difference between an interface and an abstract class?" or Java questions when recruiters don't read my resume). Third, I had one interview where they shit the bed because I pushed back ever so slightly after 20 minutes of ridiculing my solution in a third damned interview. Fourth, I used to ask to see the style guide but have since stopped because every place treats it like a state secret because God forbid I get to see if it'll be a good fit for me without wasting months being nickeled and dimed to death. I still say nobody would conceal this information if they were honest and apparently that's wrongthink.

[Zecc]

@Zenith said in Why, oh why, do we return empty things on error:

I'm not allowed to be assertive or confident.

Not with that attitude.

@Zenith said in Why, oh why, do we return empty things on error:

I can't run around naked screaming

Depends. Are you in Florida?

@Zenith said more stuff in Why, oh why, do we return empty things on error, and it was all serious and shit.

I'm sorry that you've had bad interview experiences and I sincerely hope you'll find some place you fit in soon. I for one have always avoided large companies precisely because in my mind the larger the place the more space there is for style cops and bureaucrats and nitpickers and people who are more concerned about pretending they are doing a job instead of getting shit done.

If I were an interviewer I'd be looking for signs of intelligence, ability to think algorithmically, technical knowledge, etc. I'd also be looking for the right kind of atention to detail; that is, attention to the tradeoffs your program makes, edge cases handled, etc., and not to in which line your braces fall or even if your syntax is 100% correct (there are compilers for that). I favour pragmatism over formalism.

Having said that: although I appreciate (and even like) your contrarian stance, the fact you don't follow conventions also speaks about how much of a team player you are and how pragmatic you are on a higher level: that of hacking through other people's limitations. Conventions exist for a reason, and while the majority isn't always right, it also often is. And by not following conventions you are signalling that you value more your identity than your ability to communicate.

But this is really nitpicking. Your code is readable. It's not like you've used unintelligible variable names, or silently swallowed errors, or done the sort of so much worse atrocities we've all seen out there or on this site.
And if you know for a fact you are the one who is going to read your own code the most then writing it the way you are the most comfortable is the pragmatic approach, so go for it.

[sloosecannon]

@Zenith I was going to write up some kind of pithy response to this but.. frankly.. it's not worth it.

Maybe you are that good. I know of literally nobody.. ever.. who is. But I don't know you. Maybe you are.

It's not about being confident. It's about being overconfident, which is something I'm definitely picking up from you, and I suspect any good interviewer will pick up too.

I suspect if that's the case it's not something that will ever change about you. You're not exactly at a point in life where you'll take advice from a bunch of internet randos. I also suspect you're pretty stubborn so you wouldn't anyways.

I do truly wish you better luck in your job hunt. It's... difficult and painful and sometimes damn near impossible.

[BernieTheBernie]

@robo2 said in Why, oh why, do we return empty things on error:

@boomzilla said in Why, oh why, do we return empty things on error:

No.

Correct. Kevin has got you covered:

public bool SomeMethod (int arg1, SomeType arg2, int arg3)
{
    try
    {
       // use the arguments arg1 and arg3, and attempt to fill the properties of arg2
        return true;
    }
    catch (Exception ex)
    {
        LastError = ex.Message; // LastError is global
        LastErrorStacktrace = ex.StackTrace; // another global
        return false;
    }
}

You forgot to add:
LastInnerError
LastInnerErrorStacktrace
LastInnerInnerError
LastInnerInnerErrorStacktrace
...

[dkf]

@BernieTheBernie There's always scope for converting the stack traces to strings before storing them. Because strings make everything better.

[Watson]

@dkf Strings are the universal solventformat.

[Applied Mediocrity]

@Zenith said in Why, oh why, do we return empty things on error:

You've bought into the myth that programming is disposable assembly line labor

It has been that way for a long time now. There's nothing to buy in, it's a statement of fact.
A gig where you get to participate or oversee the design of a project and also actually code stuff are rare and certainly not profitable (unless you devise some new tulip scam). Tech has evolved to the central position in everyone's lives and it simply can't harbor rockstar coding anymore. That's not to say that rockstar coding ever worked very well, but it had its ups and downs. Now everything is equally liquid and equally putrid, and it's still shit. It moves fast here, it moves slow there and you get sucked in the whirlpool.

Technology has long ago stopped being a tool. Welcome. It's now a cult. And like every cult, they require conformity and tranquility and trade you an illusion of advancement.

You're guilty of wrongthink. The industry takes care of their own, but only to sycophants with a shit-eating grin in their Shithub profile that are cargo-cult enthusiastic about everything their generous tech overlords are dropping from the cloud cover.

I feel your pain somewhat, but at the same time it's clear to me that it's simply not how things are. If you can't square with that, it's best to see if you can close this door and find another line of work. Now that tech leeches have put their grubby, slimy hands everywhere, it's going to be difficult, but anything that's not directly related will feel better.

</half->

[Zecc]

@Applied-Mediocrity said in Why, oh why, do we return empty things on error:

sycophants

I keep having to search for this word's definition, because I always imagine some sort of elephant-like pokeman with psychic powers.

[HannibalRex]

@Zecc best I can do is Musharna

[topspin]

@Zecc said in Why, oh why, do we return empty things on error:

@Applied-Mediocrity said in Why, oh why, do we return empty things on error:

sycophants

I keep having to search for this word's definition, because I always imagine some sort of elephant-like pokeman with psychic powers.

Well, that's helpful.

Filed under: Did you mean: toady

[Kamil Podlesak]

@PleegWat said in Why, oh why, do we return empty things on error:

@boomzilla said in Why, oh why, do we return empty things on error:

is retval. I have code with lots of shit that uses rtrnVal. I rename it whenever I have to do something in those methods.

We tend toward rval. Which is (almost) always an integer with 0 meaning success and -1 meaning error.

You're lucky that it's not a language where the term rval or rvalue is already defined to be something quite different. Like C and its family.

This is plain C, of course.

[dkf]

@boomzilla said in Why, oh why, do we return empty things on error:

is retval. I have code with lots of shit that uses rtrnVal. I rename it whenever I have to do something in those methods.

When I need such things, I'll usually call them result. I think that noting in the name that the variable contains a value is a level of redundancy too far, unless the code is full of variables which don't contain values for some reason.

[TheCPUWizard]

@Jaime - Bigger [IMHO] defect is the ignoring of RAII - Resource Allocation IS iInitialization. Using yur sameple that means you do not new-up SomeType until you can new-up a fully valid and acceptable for use instance.

[Jaime]

@TheCPUWizard
This is true of most of the codebase I inherited. I really looks like the original authors thought of classes more like structures. Most of the time I've tried to implement an IDisposable pattern on something, I've found that a way too much code had to be re-written, almost always because things were newed long before they were needed.

I also see a lot of: x = new y();, followed by x = GetY();, with the first instance discarded.

The really funny thing is that the original authors were much younger than me and never had any exposure to the types of languages where they might have acquired this tendency. They simply think it's "the right way".

[TheCPUWizard]

@Jaime - You write a lot of code that uses unmanaged variables? [I actually do as I have one major project that still has nearly 800K lines of C++/MFC code]

[Jaime]

@TheCPUWizard
A little - some wrappers on graphics libraries.

I have been know to implement IDisposable simply so that static analysis will suggest "using" and therefore encourage stateless coding styles.

[TheCPUWizard]

@Jaime - That is horrible, and would not pass code reviews at my firm, or at most firms I have been involved with since the inceptiopn of .Net...... There are many reasons..

THe biggests is that any class which declares a member variable that implements IDisposable MUST implement IDisposable itself. Also while it must be possible to call Dispose() multiple times, accessing any member after Disposal is supposed to throw an ObjectDisposedException.

Given that the using statement is just sugar for try {} catch {finally { x.Dispose()} and there are NO places where the compiler or runtime will ever cause dispose to be called implictly, the work involved in properly implementing IDisposable compared to being able to use the using statement is massive.

[Jaime]

@TheCPUWizard
I don't disagree with you.

But, where I work, if I get into a disagreement about if doing what I posted in originally should be allowed... the developer has been known to take it to upper management and call in simply a "stylistic choice" and accuse me of singling them out for ridicule among their peers without cause.

However, if I can make their code throw a warning, then upper management will be more likely to not back the original author since there is a "higher authority".

I know it's more work, but it's the only way I can get things done in the totally screwed up environment I find myself in.

[Jaime]

@TheCPUWizard
I once was told that code that does unsafe parameter handling in a SQL statement should be allowed because "it wasn't Internet facing".

Of course, that wasn't the real reason. The real reason was that the author took every criticism as a personal insult and was deemed necessary (to be coddled) because he had been there for 30 years and was the sole maintainer for a million lines of horrible code.

[dkf]

@Jaime said in Why, oh why, do we return empty things on error:

the sole maintainer for a million lines of horrible code

Holy low-valued bus-factor of doom, Batman!

[Jaime]

@dkf
They are literally afraid to speak an angry word to him because he wrote all the code on an obscure platform and he has a hair-trigger temper. He rage-quits at least once per year.

[dkf]

@Jaime Well, they need to plan what will happen when he retires, dies, or otherwise becomes unavailable. That's absolutely inevitable. They can either find some other sucker, rewrite, or just stop using the code. Or use it as a semi-animated corpse, a true zombie product in want of a Victor Frankenstein to figure out a set of build instructions.

[TheCPUWizard]

@Jaime - It is easy for me to say (but that does not generally make it sell true), there are other jobs and healthier work environments out there.... My (serious) deepest condolences for your situation.

[Jaime]

@dkf said in Why, oh why, do we return empty things on error:

Well, they need to plan what will happen when he retires, dies, or otherwise becomes unavailable. That's absolutely inevitable.

He's in his late 60's and just bought a house in Florida.

Three years ago I got them to declare the platform legacy and prohibit new work in it. There was agreement among everyone at the time.

I just heard that said individual is pitching to do development on one of our new projects. Of course, on said obscure platform. Senior management is actually buying arguments like "look at what can be built on this platform"... as if the difference between platforms is the that each can build vastly different things.

[Jaime]

@TheCPUWizard said in Why, oh why, do we return empty things on error:

My (serious) deepest condolences for your situation.

TBH, I don't have a lot of stress at work and they pay me well. I would love to have a job where I can actually accomplish things, but I don't feel in need of condolences.