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

[Jaime]

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

If it was finagled into being a thread local, it would work.

Even then, you only get the Message property of the original exception. This reminds me of another pattern that I see constantly:

try
{
    // Stuff ...
}
catch (Exception ex)
{
    throw new Exception(ex.Message);
}

This is especially fun when // Stuff is a large block of code and it throws something common like a null reference exception.

[MrL]

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

This reminds me of another pattern that I see constantly:

try
{
    // Stuff ...
}
catch (Exception ex)
{
    throw new Exception(ex.Message);
}

Not clear enough. Better:

try
{
    // Stuff ...
}
catch (Exception ex)
{
    throw new Exception("Exception was thrown", ex.Message);
}

[dkf]

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

throw new Exception("Exception was thrown", ex.Message);

Even better:

throw new Exception("Exception was thrown", ex.Message != null);

[BernieTheBernie]

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

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

C# does not have a Garbage Collection

Of course. If it had garbage collection that worked, it would collect Kevin's code before even compiling it.

Hey, that's the Greatest Idea for VisualStudio's next version! I'll submit it.

[Zenith]

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

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

Well, all of you can stew on this - I'm not changing my style and every line of code I write of my own accord is 100% consistent with that style.

I'm beginning to understand why you have so much trouble with interviews.

Not really. They're rarely technical. Just spirit animal questions. I usually lie and say what I think they want to hear. I've only had two code sessions in recent memory. One was the Go interview, where they were more interested in style than solutions, but too cheap to hire Go developers. They were so paranoid they asked if I was going to reformat all their code and, being on my third interview and sick of dealing with them, I said it depended on how often I had to fix it. The other was the job I got, where I've been stuck in SQL land because my SQL style (semicolons and square brackets) negated 10+ years of full stack experience (code I wrote in 2005 is still in use so fuck the hipsterscript revolving door). I've been fortunate to not have to camel case but the list (
of
stupid
rules
that
make
readability
far
more
difficult
than
it
has
to
be
is
longer
than
the
rope
I
want
to
hang
myself
with
every
morning
)
and it's irritating. I'm only doing OK because I leave bugs in the code that I'm not explicitly told to fix in the ticket, don't make any suggestions to improve anything, and "code" review is 100% style review so they think I'm doing fine (albeit slow because the format mangler usually fucks up their atrocious code while mangling it so I have even more problems to paper over). It's pretty clear to me that work is about controlling others far more than it is about delivering a quality product/service and I reiterate that nobody controls my code outside of work no matter how desperately they might wish to.

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

But you like typing System.Windows.Forms.MessageBox all the time...

I have Intellisense. So I type Sy.W.F.Me.S("wtf"); when I want a message box. Except when I've replaced it with my own alertbox.

[error]

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

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

If it was finagled into being a thread local, it would work.

Even then, you only get the Message property of the original exception. This reminds me of another pattern that I see constantly:

try
{
    // Stuff ...
}
catch (Exception ex)
{
    throw new Exception(ex.Message);
}

This is especially fun when // Stuff is a large block of code and it throws something common like a null reference exception.

I see this shit a lot in Java because of checked exceptions.

[MrL]

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

I've replaced it with my own alertbox.

Of course you did.

[MrL]

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

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

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

C# does not have a Garbage Collection

Of course. If it had garbage collection that worked, it would collect Kevin's code before even compiling it.

Hey, that's the Greatest Idea for VisualStudio's next version! I'll submit it.

You'll have to wait for VS2025 at least. Currently they are busy making it more unstable and useless.

[Zenith]

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

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

I've replaced it with my own alertbox.

Of course you did.

I needed one that I could control the formatting of and copy text from. I know, I know, why reinvent the wheel better when you can struggle working around an inferior default...

[BernieTheBernie]

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

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

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

If it was finagled into being a thread local, it would work.

Even then, you only get the Message property of the original exception. This reminds me of another pattern that I see constantly:

try
{
    // Stuff ...
}
catch (Exception ex)
{
    throw new Exception(ex.Message);
}

This is especially fun when // Stuff is a large block of code and it throws something common like a null reference exception.

I see this shit a lot in Java because of checked exceptions.

Doesn't Java provide some kind of "nested" exceptions?
E.g. like the InnerExceptionproperty of an Exception in .Net?

[topspin]

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

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

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

I've replaced it with my own alertbox.

Of course you did.

I needed one that I could control the formatting of and copy text from. I know, I know, why reinvent the wheel better when you can struggle working around an inferior default...

Ctrl+C does that in ordinary MessageBoxs.

[dcon]

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

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

People that are controlling about others' styles need to get it through their heads that their own style isn't some magical universally readable style.

It doesn't have to be. There's value in uniformity.

And things like clang-format help make it so you don't have to think about it either.

You don't need to like the style where you work (I hate ours), you just have to use the tools to

[Zenith]

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

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

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

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

I've replaced it with my own alertbox.

Of course you did.

I needed one that I could control the formatting of and copy text from. I know, I know, why reinvent the wheel better when you can struggle working around an inferior default...

Ctrl+C does that in ordinary MessageBoxs.

Ordinary message box doesn't support scrolling (it just grows until it pushes the buttons offscreen) or directly saving to a file.

[error]

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

Ordinary message box doesn't support scrolling (it just grows until it pushes the buttons offscreen) or directly saving to a file.

The kind of problems that only people doing it very wrong ever encounter.

[Zenith]

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

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

Ordinary message box doesn't support scrolling (it just grows until it pushes the buttons offscreen) or directly saving to a file.

The kind of problems that only people doing it very wrong ever encounter.

Because your workflow is The One True Workflow, right? Why can't we all limit the functionality of our programs so that they can't error out because they can't do anything?

[error]

@Zenith If you need to display more text than can fit on the screen, maybe a message box isn't the appropriate UI paradigm.

[Zenith]

@error There was also the ability to do something with the text. The example I gave was to save it to a file but it could've been a button to print it or send it back to a support team. Expecting people to know they can Ctrl+C unselectable text and load another program to do something with it is additional friction. The vast majority of the replacement code I write is to reduce friction for the programmer or the user.

[topspin]

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

@Zenith If you need to display more text than can fit on the screen, maybe a message box isn't the appropriate UI paradigm.

To be fair, he said he didn't use the normal message box, so saying it's not the appropriate tool doesn't really apply.

[error]

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

To be fair, he said he didn't use the normal message box, so saying it's not the appropriate tool doesn't really apply.

He said the default one sucked because it just stretched to fit the text. The only time I've ever seen that is when a malicious website deliberately abuses alert. It's only a "problem" if you're .

[Gąska]

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

Expecting people to know they can Ctrl+C unselectable text and load another program to do something with it is additional friction.

That is true. I never remember it myself and I doubt an average user does either.

I have created custom message boxes too. I don't remember what for anymore, but there's nothing inherently wrong with the idea. Unless you use a custom message box where the default one would suffice - then it's just retarded.

[Gąska]

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

I'd even agree that browsers shouldn't be using the OS message box here either.

They don't anymore. If for no other reason than adding the "prevent additional dialogs from this page" checkbox.

[boomzilla]

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

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

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

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

If it was finagled into being a thread local, it would work.

Even then, you only get the Message property of the original exception. This reminds me of another pattern that I see constantly:

try
{
    // Stuff ...
}
catch (Exception ex)
{
    throw new Exception(ex.Message);
}

This is especially fun when // Stuff is a large block of code and it throws something common like a null reference exception.

I see this shit a lot in Java because of checked exceptions.

Doesn't Java provide some kind of "nested" exceptions?
E.g. like the InnerExceptionproperty of an Exception in .Net?

Yes. What they should have done was throw new Exception(ex). Well, assuming Exception was really some more meaningful and custom exception. But yeah, that would have preserved all the information from the original exception.

[error]

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

Well, assuming Exception was really some more meaningful and custom exception

Maybe that's the intent of checked exceptions, and I haven't been working with Java very long now, but in practice I've only seen more vague exceptions being thrown, or just the wrong exception being thrown, because the right exception (the original exception!) wasn't on the method signature. It seems to do nothing but obfuscate.

[boomzilla]

@error 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:

Well, assuming Exception was really some more meaningful and custom exception

Maybe that's the intent of checked exceptions, and I haven't been working with Java very long now, but in practice I've only seen more vague exceptions being thrown, or just the wrong exception being thrown, because the right exception (the original exception!) wasn't on the method signature. It seems to do nothing but obfuscate.

The theory (I think) is that when you call a method, the caller shouldn't be overly worried about the low level details. If the callee gets some low level type of error (e.g., file not found) it should probably throw an exception. But methods that are just asking for some information, say, that needed to maybe be read about the file probably don't care much about the details, just whether the read succeeds or fails. But of course, you still want to keep all the information so you can diagnose the problem.

But, as usual, the real world is too stupid and/or lazy to do stuff correctly,

[dkf]

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

I see this shit a lot in Java because of checked exceptions.

You're more likely to see throw new Exception(ex); which attaches the other exception as a “cause”. (There's also suppressed exceptions, but you don't normally see any of them unless you're doing something dumb like throwing exceptions in a finally when an exception is blowing past.)

[Gąska]

@error checked exceptions are a great idea that unfortunately is completely incompatible with the inhibiting most developers. It's

Wouldn't it be nice to always know every possible exception that may be thrown by every method?

versus

Wouldn't it be nice if I didn't have to think about error handling? Or just think in general?

[dkf]

@Gąska It's all awkward because dealing with failure modes is an actually important thing for programmers to do if they want their code to not fall over when a gnat farts in its general direction. And yet you also want to minimise the amount of code space spent on error handling because it's often hard enough to understand the code even without that.

If you have checked exceptions, you tend to get the bureaucracy of Java. If you don't, you have the instability that occurs in many C# applications. (Yes, you can catch everything easily at the top level of the application/thread, but then there's hardly anything you can do about it.) I don't think it's an easy thing to balance.

[BernieTheBernie]

There's a functional extension to C#: LanguageExt.
It provides an Exceptional<T> type, but ... that won't make things easier in the end.

[TwelveBaud]

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

I'd even agree that browsers shouldn't be using the OS message box here either.

@Gąska said in Why, oh why, do we return empty things on error:

They don't anymore. If for no other reason than adding the "prevent additional dialogs from this page" checkbox.

It's because they're window modal instead of tab modal, and you don't want one tab locking out all the others

[Zenith]

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

But yeah, that would have preserved all the information from the original exception.

Except the stack trace. To keep that, you have to use throw by itself.

[boomzilla]

@Zenith 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:

But yeah, that would have preserved all the information from the original exception.

Except the stack trace. To keep that, you have to use throw by itself.

No.

[robo2]

@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;
    }
}

[TwelveBaud]

@Zenith 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:

But yeah, that would have preserved all the information from the original exception.

Except the stack trace. To keep that, you have to use throw by itself.

Java doesn't allow rethrows like that. You must throw a new Throwable with the thing you caught as the cause. Blame @error for bringing up checked exceptions and shifting the language out from under you.

[JBert]

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

@Zenith 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:

But yeah, that would have preserved all the information from the original exception.

Except the stack trace. To keep that, you have to use throw by itself.

No.

It is a C# gotcha, where a throw ex statement will (re)initialize the stacktrace. I believe the idea was that you could say var ex = new MyException(); ex.Field1 = "Foo"; ex.Field2 = "Bar"; throw ex; with the stacktrace pointing to the line throwing it.

[boomzilla]

@JBert 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:

@Zenith 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:

But yeah, that would have preserved all the information from the original exception.

Except the stack trace. To keep that, you have to use throw by itself.

No.

It is a C# gotcha, where a throw ex statement will (re)initialize the stacktrace. I believe the idea was that you could say var ex = new MyException(); ex.Field1 = "Foo"; ex.Field2 = "Bar"; throw ex; with the stacktrace pointing to the line throwing it.

Yes.

[dkf]

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

It is a C# gotcha, where a throw ex statement will (re)initialize the stacktrace.

Initialising the stack trace on first throw is fine. Reinitialising it is not. (It's not like the cost of checking if it's already there is large by comparison with the cost of generating a stack trace; the reverse is definitely true.)

[sloosecannon]

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

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

Well, all of you can stew on this - I'm not changing my style and every line of code I write of my own accord is 100% consistent with that style.

I'm beginning to understand why you have so much trouble with interviews.

I was trying to think of a way to say that without coming across as too much of an asshole, but... this.

[Zenith]

@sloosecannon I deliberately pushed code I knew had bugs in it to production today. They're paying me to complete tasks, not share expertise or take initiative. I knew they'd all get through because code review is always style review first and foremost. The brackets were "right" so it sailed on through because that's all that mattered. Congratulations.

[sloosecannon]

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

@sloosecannon I deliberately pushed code I knew had bugs in it to production today. They're paying me to complete tasks, not share expertise or take initiative. I knew they'd all get through because code review is always style review first and foremost. The brackets were "right" so it sailed on through because that's all that mattered. Congratulations.

We've had this discussion before on here, as I recall.

Code style isn't just about whether the brackets are in the right place, even if that's how you've seen it enforced or what you think it's about. It's about standardizing things so that other people can come in and read your code later and not have an aneurysm doing so. It's about not having 15 different ways to write variable names spread across the code. It's about standardizing calling conventions, error handling, etc and having your code look and behave like everyone else's.

Your sample above is... bizzare. It's definitely not something I'd expect to run into in a normal codebase. I can figure out what it's doing, if I sit down and look closely at it, but if I've been tasked to fix a bug and I'm 4 hours in, the last thing I want to do is look at code that's hard to read (because it looks different than everything else) and is weird.

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.

[MrL]

@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;
    }
}

[Zenith]

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

Especially if your reaction when prompted about code style questions is similar to how you react on this forum.

But posting a picture of somebody pouring bleach in their eyes is totally kosher. Right, how dare I take and defend an opposing view! Clearly your way is the only way Dear Leader. I'll be sure to genuflect frequently while I fix mountains of bugs that don't exist in codebases written my way even though it's automatically wrong for being different.

I wonder if you see the parallels to big tech's unilateral enforcement of collectivist groupthink.

[sloosecannon]

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

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

Especially if your reaction when prompted about code style questions is similar to how you react on this forum.

But posting a picture of somebody pouring bleach in their eyes is totally kosher. Right, how dare I take and defend an opposing view! Clearly your way is the only way Dear Leader. I'll be sure to genuflect frequently while I fix mountains of bugs that don't exist in codebases written my way even though it's automatically wrong for being different.

I wonder if you see the parallels to big tech's unilateral enforcement of collectivist groupthink.

The source for that remark is based not only on this thread, but on your comments about code style guidelines made elsewhere in the forum. I was not the one who posted eye bleach as a response to your code.

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, and if you're writing code for a team, and you're writing completely differently from everyone else on that team, it's going to make things confusing for everyone else. You may not see this as a problem. But the people who are in charge of hiring the most efficient possible candidate will have a problem with that, because 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.

I love your attempt to shoehorn some kind of comment about "collectivist groupthink" in this post though. Maybe next time you can go for two and sneak in a needful doers reference?

[Jaloopa]

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

You have a rotten luck for getting shitty interviews

I think at this point it's well past bad luck and into "the reason you smell shit everywhere is because you stepped in shit" territory. I suspect the "everyone is obsessed with style guidelines" thing is actually "I'm obnoxious about my own One True Style and won't ever compromise on staying consistent with existing styles"

[Jaloopa]

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

Acronyms are capitalized in English.

A laser sharp observation that's as deep as a scuba diver

[Zecc]

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

People that are controlling about others' styles need to get it through their heads that their own style isn't some magical universally readable style.

I agree with this proposition in general, but not when you're defending that

return ((Integer_Out = 0) != null);

// and

return ((Integer_Out = null) != null);

is more readable than

Integer_Out = 0;
return false;

// and

Integer_Out = null;
return true;

or even, if you really want to make explicit what the return value represents,

Integer_Out = 0;
return (Integer_Out != null);

// and

Integer_Out = null;
return (Integer_Out != null);

.

[Zecc]

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

Name stuff right and var is never a guessing game.
There's no additional information in this:

Dictionary<string, FrobnicatorService> services = new Dictionary<string, FrobnicatorService>();

over this

var  services = new Dictionary<string, FrobnicatorService>();

and no important information lost in this

Some new version of C# introduced this and I like it:

Dictionary<string, FrobnicatorService> services = new();  // Could take parameters if necessary

[Zecc]

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

Or when some asshole names their class Collection or Dictionary or List or TextBox or Iterator.

That's an argument in favour of fully qualifying Collection or Dictionary or List or TextBox or Iterator (and in those cases, I would fully qualify them), but it's also an argument in favour of using keyword types when possible, since those can't possibly refer to something else.

[Zecc]

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

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

If it was finagled into being a thread local, it would work.

Even then, you only get the Message property of the original exception. This reminds me of another pattern that I see constantly:

try
{
    // Stuff ...
}
catch (Exception ex)
{
    throw new Exception(ex.Message);
}

This is especially fun when // Stuff is a large block of code and it throws something common like a null reference exception.

Or even

catch(Exception ex)
{
    Log.Error("Exception! {0}", ex.Message);
    throw ex; // In C#, there goes the original exception site
}

[Zecc]

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

Expecting people to know they can Ctrl+C not just screenshot anything even if there is unselectable text and load another program to do something with it is additional friction. is naïve



[Zenith]

@sloosecannon Your problem (and maybe your's too @Jaloopa) is that you don't respect the profession or individualism. You've bought into the myth that programming is disposable assembly line labor. That you're a cog to be parachuted into random disaster after random disaster like a day labor janitor. If that's what you think of yourself or, God forbid, people that you manage, I feel sorry for you and them. Because if that's all the higher you set the bar, that's all you're going to get - uninspired, mediocre, cookie-cutter work from people there just to collect a paycheck.

There are only two reasons everybody's code "must" look and act exactly the same. One, the absurd notion that every developer must wear every hat on every project, and two, creeping authoritarianism. I can't change bad project management but I sure as hell make a point to keep my authoritarian impulses in check.

Now I've really had enough of this. We're not going to change each other's mind. If you'd like, we can take turns posting every time the other posts a block of code.

while (Boolean_HandsColdAndDead == false){Zenith.TDWTF.WriteCode(Zenith.Constants.PASCALCASING);}