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

Jaime

I reviewed another commit today and saw this pattern repeat for the zillionth time:

public SomeType SomeMethod (int arg1, int arg2)
{
    var retval = new SomeType();
    try
    {
       // use the arguments and attempt to fill the properties of retval
    }
    catch (Exception ex)
    {
        LogError(ex);
    }
    return retval;
}

Nothing ever errors, every call succeeds. Sometimes, it succeeds and you get an empty object... if so, the actual problem (probably) got logged. If you forget to take a deep look at the return value, you'll probably get an NPE at some point later in the code when you've assumed that you have an object in a valid state.

The worst part about this particular bug is that the code would be better if it simply "didn't". Take out the try/catch, take out the bogus new on top. Our programmers spend a lot of time writing code that makes our lives harder.

Grunnen

@Jaime Then remove the default constructor of SomeType and add a constructor that obligatorily initializes it into a valid state.

boomzilla

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

Jaime

@Grunnen
So.... that will make SomeMethod not compile. Problem solved.

Except... some genius put all of the shared code for all of the major projects in the same library. So, since much of our code works this way, once I do this, It'll cause umpteen thousand compile errors across 20 applications. Fine.

Except... we do this in REST and Web Service methods too. So, the clients of those will have to be modified. When I stepped into this job, there was no good tracking of any of this stuff so there's no way I'll find even half of it.

Also, I'm struggling to get people to stop making more of it, I'd love to have enough time to fix the existing stuff, but my time is spent reviewing code and trying to teach people why this isn't a good idea. I can't prevent it in new code because SomeType is often a new type that is written by the same developer.

boomzilla

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

@Jaime Then remove the default constructor of SomeType and ~~add a constructor that obligatorily initializes it into a valid state.~~let their shitty code crash and burn and break the build and then throw a blanket party for them.

Jaime

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

add a constructor that obligatorily initializes it into a valid state.

Funny. Look at the code flow. The invalid object gets returned when bad things happen - bad things like "can't connect to the database". What's a valid state for an object when you can't talk to the database?

Jaime

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

let their shitty code crash and burn

Wouldn't that be nice. Unfortunately, their code usually has no error handling, so the only effect will be 75 tickets thrown in my general direction with the title "Jaime's service broke again".

Seriously, their code usually only survives this because they have no error handling and their code simply does nothing in these cases. Somebody reboots a server or re-runs a flakey data load process, tells them to try again, and the problem is declared solved.

boomzilla

@Jaime I know. I was just venting.

Jaime

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

is retval

PleegWat

@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.

This is plain C, of course. Commonly the reason we're transporting the return status is we have to release some resource (like a file descriptor or lock) and want to centralize the cleanup.

boomzilla

@PleegWat yeah...I guess I could see that in your case. But not when its type is actually SomeObject.

PleegWat

@boomzilla If it was returning a pointer to SomeObject then the variable would be called so (and be NULL on error because plain C no exceptions).

Which gets when the function returns a linked list of SomeObjects. Because then you cannot distinguish between real errors and no data found.

Unperverted Vixen

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

The worst part about this particular bug is that the code would be better if it simply "didn't". Take out the try/catch, take out the bogus new on top. Our programmers spend a lot of time writing code that makes our lives harder.

Depends on where this code is used. If this is called from within an ASMX WebMethod... well, those completely bypass the ASP.NET global error handler, so you lose the exception entirely if it's not explicitly caught/logged by something in the method chain.

Zenith

@Jaime It's a stupid pattern but may be a carryover from non-nullable types.

I always preferred:

public static System.Boolean SomeFunction (System.Int32 Integer_In, out System.Int32? Integer_Out, ref Zenith.Stack Object_Stack)
{
  try
  {
    //some stuff
    return ((Integer_Out = 0) != null);
  }
  catch (System.Exception Exception_Failure)
  {
    Zenith.Stack.LogError(Exception_Failure);
    Zenith.Stack.SafeSave(Object_Stack, Exception_Failure);
    return ((Integer_Out = null) != null);
  }
}

But it's not design patterny enough for enterprisey hipsterscript.

Jaime

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

Depends on where this code is used

Not really. This method returns an instance of SomeType. Under no circumstances should it return an invalid instance when it did not complete its task. There are a number of valid alternatives, but none of them return a default object on error. The alternatives I can think of are:

Return an instance on success, throw exception on error, return null if no data found.
Return an instance on success, throw exception on error or if no data found.
Return a structure with a result code and an instance. Result code is zero and instance populated for success, result code non zero and instance null for failure.
Return int, take a ref argument. Set argument and return zero on success. return non zero and ignore argument on failure.

Your comment about Web Service not triggering the global error handler is valid, but that's just an implementation detail about how to properly log errors, not about how to design the method signature. Obviously, if this were in a web method call, the catch would still be needed because general design considerations don't override technology-specific quirks.

Gąska

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

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

What's the point of the comparison? Do you not trust Roslyn to generate the right bytecode or do you just hate writing return false?

And using the result of an assignment operator is just a dick move.

Zenith

@Gąska 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:

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

What's the point of the comparison? Do you not trust Roslyn to generate the right bytecode or do you just hate writing return false?

Often the true end of this is return (Object_X != null); because it's possible for nothing to fail but still generate a bad result and I like symmetry so the false end follows the same pattern (while also shortening the code by a line).

And using the result of an assignment operator is just a dick move.

Not if you know what you're doing. I don't do anything stupid with operator overloading and I don't feel like dumbing down my code for framework monkeys.

MrL

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

public static System.Boolean SomeFunction (System.Int32 Integer_In, out System.Int32? Integer_Out, ref Zenith.Stack Object_Stack)
{
  try
  {
    //some stuff
    return ((Integer_Out = 0) != null);
  }
  catch (System.Exception Exception_Failure)
  {
    Zenith.Stack.LogError(Exception_Failure);
    Zenith.Stack.SafeSave(Object_Stack, Exception_Failure);
    return ((Integer_Out = null) != null);
  }
}

Zenith

@MrL Because you'd rather wonder about the return value or wade through a 3-page red ASP.NET stack trace?

MrL

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

@MrL Because you'd rather wonder about the return value or wade through a 3-page red ASP.NET stack trace?

Because of... let's see:

System.Boolean, System.Int32, System.Exception
Integer_In, Object_Stack, Exception_Failure
((Integer_Out = 0) != null), ((Integer_Out = null) != null)
val + out +ref

Gąska

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

@Gąska 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:

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

What's the point of the comparison? Do you not trust Roslyn to generate the right bytecode or do you just hate writing return false?

Often the true end of this is return (Object_X != null); because it's possible for nothing to fail but still generate a bad result and I like symmetry so the false end follows the same pattern (while also shortening the code by a line).

And using the result of an assignment operator is just a dick move.

Not if you know what you're doing.

I didn't say it's incorrect or not allowed or asking for trouble or anything like that. It's just a dick move. Makes code harder to read for no benefit. "Okay so this does some stuff, and then it calls this and this, and this goes here, and that goes there, and then it returns that comparison, okay so when this and this then the return is true and otherwise it's false, and when you OH MY GOD THERE'S AN ASSIGNMENT IN THE MIDDLE OF THAT RETURN STATEMENT THAT CHANGES EVERYTHING."

Pointless comparisons that always give the same result are in the same bucket. YOU know that they're essentially return false. But people who may inherit your code years later don't. And if they're decent programmers, they'll remember the Chesterton's fence and spend hours wondering just what the hell you were trying to achieve. Maybe you just like pointless comparisons, or maybe you were working around a compiler bug in a particular patch version of .Net Framework. IIRC @dkf has some stories of having to write C code in a very particular way to make the only compiler available for an obscure embedded platform happy.

There's nothing inherently wrong with your coding style, but it's still a dick move.

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:

@MrL Because you'd rather wonder about the return value or wade through a 3-page red ASP.NET stack trace?

Because of... let's see:

System.Boolean, System.Int32, System.Exception

Integer_In, Object_Stack, Exception_Failure

((Integer_Out = 0) != null), ((Integer_Out = null) != null)

Yeah, well, it's nowhere near as ugly as camel casing, every bracket style but Allman, and dozens of other weird style choices.

val + out +ref

Nothing wrong with this. The inputs are listed first, then the outputs, and finally that stack object (that's at the end of every function). It makes perfect sense. Especially if you think about how assembler and registers work. Low level instructions don't return anything; they just put the result(s) in another memory location.

Zenith

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

There's nothing inherently wrong with your coding style, but it's still a dick move.

OK, I can accept that compromise.

MrL

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

@MrL Because you'd rather wonder about the return value or wade through a 3-page red ASP.NET stack trace?

Because of... let's see:

System.Boolean, System.Int32, System.Exception

Integer_In, Object_Stack, Exception_Failure

((Integer_Out = 0) != null), ((Integer_Out = null) != null)

Yeah, well, it's nowhere near as ugly as camel casing, every bracket style but Allman, and dozens of other weird style choices.

System.Boolean, System.Int32, System.Exception

Unneeded namespaces, they serve no purpose. Framework type names for no reason also.

Integer_In, Object_Stack, Exception_Failure

Hungarian notiation, which makes no sense in C#, except worse because of underscores.

((Integer_Out = 0) != null), ((Integer_Out = null) != null)

Weird and confusing.

So overall a lot of unneeded typing (and reading), hard to understand, not what anyone would expect in C#.

val + out +ref

Nothing wrong with this. The inputs are listed first, then the outputs, and finally that stack object. It makes perfect sense.

What does this method actually return? An int or success status? Weird - looks like error handling in Go.

public bool? SomeFunction (int in)
{
  try
  {
    //some stuff
    return result;
  }
  catch (Exception e)
  {
   Logger.LogException(e);
   return null;
  }
}

topspin

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

Integer_In, Object_Stack, Exception_Failure

Hungarian notiation, which makes no sense in C#, except worse because of underscores.

I’m going to assume that’s not Hungarian notation but just dummy variable names for dummy code. Might as well be “Name_In” or something.

MrL

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

Integer_In, Object_Stack, Exception_Failure

Hungarian notiation, which makes no sense in C#, except worse because of underscores.

I’m going to assume that’s not Hungarian notation but just dummy variable names for dummy code. Might as well be “Name_In” or something.

Ah, you may be right.

Zenith

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

System.Boolean, System.Int32, System.Exception

Unneeded namespaces, they serve no purpose. Framework type names for no reason also.

So what? It's also consistent.

Integer_In, Object_Stack, Exception_Failure

Hungarian notiation, which makes no sense in C#, except worse because of underscores.

So what? Lowercased acronyms don't make sense either.

((Integer_Out = 0) != null), ((Integer_Out = null) != null)

Weird and confusing.

Not really.

So overall a lot of unneeded typing (and reading), hard to understand, not what anyone would expect in C#.

Meanwhile, be sure to not line up your brackets (that's hard to read) and copy var from ~~Visual Basic~~ hipsterscript so every declaration's a guessing game.

val + out +ref

Nothing wrong with this. The inputs are listed first, then the outputs, and finally that stack object. It makes perfect sense.

What does this method actually return? An int or success status? Weird - looks like error handling in Go.

public static System.Boolean SomeFunction (System.Int32 Integer_In, out System.Int32? Integer_Out, ref Zenith.Stack Object_Stack)

Literally, it returns a boolean. Functionally, it returns both a boolean and an integer. The success or failure of the function (boolean) is decoupled from the application-relevant result (integer). It's the same pattern as every TryParse() in the framework (which I usually discard in favor of nullable Convert(object, default) style functions).

public bool? SomeFunction (int in)
{
  try
  {
    //some stuff
    return result;
  }
  catch (Exception e)
  {
   Logger.LogException(e);
   return null;
  }
}

Interestingly enough, your solution was shit all over when I attempted it in an interview. By a Go developer. For a job seeking C# developers interested in learning Go. Those assholes put me through three interviews, where I was the only person to pass the tests, and then turned me down over my code style.

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

I’m going to assume that’s not Hungarian notation but just dummy variable names for dummy code. Might as well be “Name_In” or something.

Nope, that's my code style, a modified Hungarian.

Gąska

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

By a Go developer.

Go developers have no sense of taste (or just no sense in general). Don't listen to them. Remember, there's only ever been one Go fan on this forum, and he speaks Lojban.

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

Nope, that's my code style, a modified Hungarian.

Now I really hate you.

dcon

@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.

I've often used rc (return code). Usually just for integers.

MrL

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

System.Boolean, System.Int32, System.Exception

Unneeded namespaces, they serve no purpose. Framework type names for no reason also.

So what? It's also consistent.

Unnecessary typing, which introduced no new information, it's just noise.
And it's not consistent, because you don't expect anything like this in common C#.

Integer_In, Object_Stack, Exception_Failure

Hungarian notiation, which makes no sense in C#, except worse because of underscores.

So what? Lowercased acronyms don't make sense either.

Of course they do, when done right. Naming is hard.
Hungarian is unnecessary noise again.

((Integer_Out = 0) != null), ((Integer_Out = null) != null)

Weird and confusing.

Not really.

Yes, really, because noone writes like that. And because it's unexpected it's hard to understand quickly. Not for you, I know, but for other people that will read it after you.

Meanwhile, be sure to not line up your brackets (that's hard to read) and copy var from ~~Visual Basic~~ hipsterscript so every declaration's a guessing game.

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
var frobnicatorServices = frobnicatorFactory.GetServices();
over this
Dictionary<string, FrobnicatorService> frobnicatorServices = frobnicatorFactory.GetServices();

Of course using var in every situation is stupid.

Literally, it returns a boolean. Functionally, it returns both a boolean and an integer. The success or failure of the function (boolean) is decoupled from the application-relevant result (integer).

No need to decouple when you check for failure anyway.

It's the same pattern as every TryParse() in the framework (which I usually discard in favor of nullable Convert(object, default) style functions).

TryParse works this way because there were no nullables in C# 1.

Interestingly enough, your solution was shit all over when I attempted it in an interview. By a Go developer.

Well there you go: Go developer.

For a job seeking C# developers interested in learning Go. Those assholes put me through three interviews, where I was the only person to pass the tests, and then turned me down over my code style.

You have a rotten luck for getting shitty interviews.

Zenith

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

So what? It's also consistent.

And it's not consistent, because you don't expect anything like this in common C#.

Yes, it is, because you're doing all of your declarations the same way. It's ridiculous that DateTime and TimeSpan are practically primitives but don't have a cute blue shortcut like int and float. Better to declare them all the same way.

So what? Lowercased acronyms don't make sense either.

Of course they do, when done right. Naming is hard.

No, they don't. Acronyms are capitalized in English. And what's really stupid is when the style wackos arbitrarily change that rule based on the length of the acronym, uppercasing IO and lowercasing SQL. Why not just change it based on the first letter, uppercasing A-M and lowercasing N-Z? It would be just as arbitrarily nonsensical.

No need to decouple when you check for failure anyway.

When you need the result at runtime and not after parsing an error log. Unless you want to argue that checking for null or an error property isn't extra useless typing. I hate having to type Structure_Whatever.value.property every time I need to get at a nullable struct.

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's just as fucking alien to those others as you think mine is. It's basically the programming equivalent to the ugly American stereotype wondering why the rest of the world doesn't give up their gibberish and learn English.

Zenith

I'm honestly tired of dealing with systems where a so-called "architect" said "everyone will type exactly like me or else" and dusted off their hands at a job well done without even thinking about actual architectural issues like directory structure or exception handling.

Gąska

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

So what? It's also consistent.

And it's not consistent, because you don't expect anything like this in common C#.

Yes, it is, because you're doing all of your declarations the same way. It's ridiculous that DateTime and TimeSpan are practically primitives but don't have a cute blue shortcut like int and float. Better to declare them all the same way.

Okay but why the fuck fully qualified names? Do you write System.Windows.Forms.MouseEventArgs too?

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's just as fucking alien to those others as you think mine is.

The difference is, one of you uses Microsoft's official style guide that almost the entire C# community sticks to, and the other refuses to use basic language keywords.

Zenith

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

Okay but why the fuck fully qualified names? Do you write System.Windows.Forms.MouseEventArgs too?

Clarity and yes. I'm not so slow a typist or reader that it impacts me.

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

The difference is, one of you uses Microsoft's official style guide that almost the entire C# community sticks to, and the other refuses to use basic language keywords.

Oh you sweet summer child, you really think they follow it. Once you realize that a style ~~guide~~ dictate is a weapon wielded by the most politically powerful developer/manager, you'll see all of the cracks in that facade. Not even Microsoft follows their own rules.

Gąska

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

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

Okay but why the fuck fully qualified names? Do you write System.Windows.Forms.MouseEventArgs too?

Clarity

cfe1e187cd5703d9d1513ae24937b4839e3a7f1c97972667f576b79a1b2874a6.jpg

I'm attaching a WinForms mouse event listener to a WinForms button control in a constructor of WinForms window in a project that's entirely WinForms, just which MouseEventArgs it could possibly be!

sloosecannon

@Gąska 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:

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

Okay but why the fuck fully qualified names? Do you write System.Windows.Forms.MouseEventArgs too?

Clarity

I'm attaching a WinForms mouse event listener to a WinForms button control in a constructor of WinForms window in a project that's entirely WinForms, just which MouseEventArgs it could possibly be!

No it makes sense. There's so many other Int32 classes to get confused with...

Filed Under: Or maybe he just lost his source code and had to decompile it. That would explain the full namespaces...

PleegWat

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

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

There are a very few places where using the result of the assignment operator is the right thing to do. This is not one of them.

Zenith

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

@Gąska 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:

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

Okay but why the fuck fully qualified names? Do you write System.Windows.Forms.MouseEventArgs too?

Clarity

I'm attaching a WinForms mouse event listener to a WinForms button control in a constructor of WinForms window in a project that's entirely WinForms, just which MouseEventArgs it could possibly be!

No it makes sense. There's so many other Int32 classes to get confused with...

Filed Under: Or maybe he just lost his source code and had to decompile it. That would explain the full namespaces...

Or when some asshole names their class Collection or Dictionary or List or TextBox or Iterator. Look, style Nazis are always screeching about consistency. This is consistent, using fully qualified .NET names for all types, and somehow there's still a problem with it. You don't want internal consistency, you want consistency with your inconsistency.

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.

dkf

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

we do this in REST and Web Service methods too

If this was Java, you could set up some exception mappers and then the exceptions would become the right (probably error) responses. I'm less sure about C# (?) but I'd be startled if there wasn't something similar.

BernieTheBernie

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

I reviewed another commit today and saw this pattern repeat for the zillionth time:
public SomeType SomeMethod (int arg1, int arg2)
{
    var retval = new SomeType();
    try
    {
       // use the arguments and attempt to fill the properties of retval
    }
    catch (Exception ex)
    {
        LogError(ex);
    }
    return retval;
}
Nothing ever errors, every call succeeds. Sometimes, it succeeds and you get an empty object... if so, the actual problem (probably) got logged. If you forget to take a deep look at the return value, you'll probably get an NPE at some point later in the code when you've assumed that you have an object in a valid state.

The worst part about this particular bug is that the code would be better if it simply "didn't". Take out the try/catch, take out the bogus new on top. Our programmers spend a lot of time writing code that makes our lives harder.

You haven't worked with Kevin yet. Let me rewrite that snippet the Kevin style:

 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
         return false;
     }
 }

That is, arg2 must be instantiated in the calling function (well you know, somewhere you must handle the lifetime events of that object, since C# does not have a Garbage Collection).
Of course, all properties of arg2 are public read-write: you can never be sure where else they might have been written, happy debugging!
The boolean return value may or may not be checked.
LastError could also be a stale value from some earlier failure, or just be reset to null at some other point without checking.

MrL

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

// LastError is global

BernieTheBernie

@MrL If you do not fail to perform it in the wrongly correct way, the thing may simply slip down instead of delivering the ~~expected~~ desired result.

MrL

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

@MrL If you do not fail to perform it in the wrongly correct way, the thing may simply slip down instead of delivering the ~~expected~~ desired result.

We'll just try and try again until desired result is achieved. It's worth it.

MrL

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

Yes, it is, because you're doing all of your declarations the same way.

Everything is consistent given small enough scope. Problem is - practical scope here is team/company.

It's ridiculous that DateTime and TimeSpan are practically primitives but don't have a cute blue shortcut like int and float.

Orange. Keywords are orange.

No, they don't. Acronyms are capitalized in English.

Code is not English.

And what's really stupid is when the style wackos arbitrarily change that rule based on the length of the acronym, uppercasing IO and lowercasing SQL. Why not just change it based on the first letter, uppercasing A-M and lowercasing N-Z? It would be just as arbitrarily nonsensical.

Length differentiation in this rule is meant to discourage people from coming up with 20 charaters acronyms and/or peppering codebase with lumps of capitals. But you are right, it's clunky. I would just camelCase everything.

When you need the result at runtime and not after parsing an error log. Unless you want to argue that checking for null or an error property isn't extra useless typing.

It isn't, wtf.

I hate having to type Structure_Whatever.value.property every time I need to get at a nullable struct.

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

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.

dkf

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

IIRC @dkf has some stories of having to write C code in a very particular way to make the only compiler available for an obscure embedded platform happy.

There's two compilers, but one tries to emulate the other. Except for asm { … }, of course. (The real horrible bits have to do with making IDEs not barf on fixed point constants; the compilers are happy, but the GUI just goes round the bend as soon as it sees 0.1k and isn't to happy at unsigned long accum as a type either.)

Or maybe you were referring to that one compiler bug where multiplying by a negated variable caused an internal compiler fault, where all the various bits and pieces of operations were merged in from several functions (in multiple files) and the results reported against (the platform's equivalent of) main() that was in a totally different file. That wasn't so much contortion as just plain old weird to debug (the confusion was due to aggressive inlining options being enabled; the fix was to pre-negate the constant during setup of the application data, with a net code delta of moving a - from one file to another).

dkf

@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.

Jaime

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

You haven't worked with Kevin yet. Let me rewrite that snippet the Kevin style:

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
        return false;
    }
}

At least "Kevin style" (in this case) is pretty close to how a transplanted C programmer would do it, just change the return type to int instead of bool and it's "the right way" for most non garbage collected languages. If I saw that method signature come up in IntelliSense, I would immediately know how to call it.

The originally posted style does nothing but make the caller think more and work more.

I do, however, admit that the LastError bit is something that makes me feel sad for you.

dkf

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

I do, however, admit that the LastError bit is something that makes me feel sad for you.

If it was finagled into being a thread local, it would work. (That's how errno works in most C interfaces to the POSIX system call API.) Otherwise, if it is an ordinary instance property then you can also get away with it providing the object is effectively thread-bound. Any other option is just B. A. D.

It's still stupid, given that exceptions exist.

boomzilla

@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.

It's part of your charm.

HardwareGeek

@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.