null vs String.Empty

Nemanja Trifunovic

Dario Solera wrote:

It could be correct, if the method actually fails.

Chris explicitelly said "fails", whatever he meant by that :)

Dario Solera

Nemanja Trifunovic wrote:

Chris explicitelly said "fails", whatever he meant by that

Yes, sorry, I noticed it too late... :)

________________________________________________ Tozzi is right: Gaia is getting rid of us. Personal Blog [ITA] - Tech Blog [ENG] Developing ScrewTurn Wiki 1.0 final, now in English, Italian and German.

realJSOP

I return an empty string.

"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001

Andy Brummer

I would definitely never use String.Empty. Using a valid string as an error code is just crazy talk. I would normally throw an exception, unless "failure" is common or profiling warranted removing the exception. Then I would return a flag and make the string a ref or an out parameter. I'm concerned that the question itself might be a lingering symptom of your VBScript hacking days. Just open an old C++ COM app and breathe in the putrid stench of all those HRESULTS and the path ahead should become clear. :-D

I can imagine the sinking feeling one would have after ordering my book, only to find a laughably ridiculous theory with demented logic once the book arrives - Mark McCutcheon

Jeremy Falcon

Judah Himango wrote:

If the function fails for any reason (say, bad input, maybe specifying a negative number as the index), then you throw an exception.

Even in that instance, I'd still return NULL or true/false. It's the goal of the function do what it's supposed to do and if it can't, even if it gets bad params, let the caller know rather than just throw an exception (unless that exception is used to let the caller [programmer] know rather than just dump text in a message box and hope to the computer gods it fixes itself). The idea is program flow. I wouldn't want mine left up to the UI unless I wanted the UI to hang it. And if that's the case the caller would know to do on a per call basis. This also helps me to reuse the function in a more generic manner. And of course, I do a lot of C programming too. So, try/catch is out the window for me anyway. :-D

Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]

Jeremy Falcon

Null always, it's quicker, less memory, etc. Also, an empty string could be a valid value whereas Null is never thought to be one. Anyone that uses an empty string needs to lay down the VB books IMO. ;P It's wasted time and memory. Not to mention, slower to compare against.

Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]

Anand Vivek Srivastava

I return an null because it would invariably have to handled by the caller, an empty string might escape being handled by mistake, a null is very easy to locate. (and String.Empty is very ofter a valid return value) As some people have already pointed out, returning a bool and making the string a parameter is a better idea if throwing an exception is not an option.

led mike

Jeremy Falcon wrote:

Anyone that uses an empty string needs to lay down the VB books IMO

That's just foolish.

led mike

Chris Maunder

Zac Howland wrote:

I take it this is in Java?

<looks around at all the C# code lying about the place, then looks under books and desks for signs of Java code> err, no :D

cheers, Chris Maunder

CodeProject.com : C++ MVP

Chris Maunder

LOL. Yeah, I could definitely do public bool GetAString(out string aString) but, well... X|

cheers, Chris Maunder

CodeProject.com : C++ MVP

Chris Maunder

I love it how a discussion on programming techniques invariable leads to a general slamming of VB. Poor VB...

cheers, Chris Maunder

CodeProject.com : C++ MVP

Shog9 0

If by "fails" you mean "encounters a situation where it is completely unable to fulfill the requirements for which it was designed", then i go with Nemanja's technique: throw an exception. Otherwise, it depends on the situation. If the routine is designed such that the caller will need to take specific action in the event of failure, i'll return null. However, if i intend the return value to be used in the same manner regardless of whether the routine is able to actually produce anything interesting (retrieve a column value, format a date, etc.), then i'll return an empty string. In nearly all cases, this is a decision i would make prior to actually implementing the routine. In C++, it would effect my decision to use a return value of [CString|std::string|_bstr_t] vs. [LPCTSTR|char*|BSTR|etc.]. In a .NET language, it would merely change how i documented and called the routine.

---- Scripts i’ve known... CPhog 1.8.2 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages In-place Delete 1.0 - AJAX-style post delete Syntax 0.1 - Syntax highlighting for code blocks in the forums

Shog9 0

Chris Maunder wrote:

but, well...

But, well, that would be entirely appropriate if you were returning a primitive type such as int, where (depending on the purpose of the routine) it might not have any potential values that could be considered "invalid". While it usually makes more sense to treat strings as reference types, if your interface returns only primitives and strings it might be worthwhile to treat them in a similar fashion, just for consistency.

---- Scripts i’ve known... CPhog 1.8.2 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages In-place Delete 1.0 - AJAX-style post delete Syntax 0.1 - Syntax highlighting for code blocks in the forums

Shog9 0

Chris Maunder wrote:

Poor VB...

I have a meeting next week to discuss the redesign of a library, currently implemented in VB.NET and Excel. This is gonna cast a shadow over my entire weekend. No sympathy.

---- Scripts i’ve known... CPhog 1.8.2 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages In-place Delete 1.0 - AJAX-style post delete Syntax 0.1 - Syntax highlighting for code blocks in the forums

Shog9 0

Zac Howland wrote:

Returning a string("") or CString("") would be almost equivalent to String.Empty.

Unless your return value is defined as LPCTSTR... at that point, it becomes a logic error. ;P

---- Scripts i’ve known... CPhog 1.8.2 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages In-place Delete 1.0 - AJAX-style post delete Syntax 0.1 - Syntax highlighting for code blocks in the forums

Andy Brummer

Yeah, I really don't like that either, but it does signify that it is a performance hack optimization when you see it in code. Then again I only really care if it is a public method that is going to get reused all over the place. I much prefer string GetString() because it is so much more readable, and I normally don't worry about it too much because I've never run into a situation where throwing exceptions has been a performance problem. 95% of the performance problems I've run into have been lame database code that gets too friendly with the databse server.

I can imagine the sinking feeling one would have after ordering my book, only to find a laughably ridiculous theory with demented logic once the book arrives - Mark McCutcheon

Andy Brummer

Great, now I have to amend my statement. Yeah, if returning an empty string makes the general case for the client easier then yeah that is the way to go. I'd only do that in user interface code, because functions in other parts of an app should pretend they don't know how they are going to get used.

I can imagine the sinking feeling one would have after ordering my book, only to find a laughably ridiculous theory with demented logic once the book arrives - Mark McCutcheon

Shog9 0

Andy Brummer wrote:

I'd only do that in user interface code, because functions in other parts of an app should pretend they don't know how they are going to get used.

Right. :) I write a lot of UI code, so that tends to be the first scenario that occurs to me.

---- Scripts i’ve known... CPhog 1.8.2 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages In-place Delete 1.0 - AJAX-style post delete Syntax 0.1 - Syntax highlighting for code blocks in the forums

Judah Gabriel Himango

Jeremy Falcon wrote:

even if it gets bad params

I'm a believer that once you start tolerating bad input, your whole system gets messed up. In my experience, it's best to stop when you get bad input, otherwise all sorts of things start going wrong. Of course, since you're writing C, exceptions are out of the question for you. The best you can do is return soon as you get bad input, and hope the caller checks your error code.

Tech, life, family, faith: Give me a visit. I'm currently blogging about: Dumbest. Movie. Title. Evaaar. The apostle Paul, modernly speaking: Epistles of Paul Judah Himango

Zac Howland

Chris Maunder wrote:

looks around at all the C# code lying about the place

:sigh: I've used C# so much that I completely forgot it also had a String.Empty ... :doh:

If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac