null vs String.Empty

[Dario Solera]

Nemanja Trifunovic wrote:

Neither. If a function "fails", I simply throw an exception.

It could be correct, if the method actually fails. A null indicates some "void" result, I guess, and not necessarily a failure or error. :)

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

[Graham Bradshaw]

Neither. I would never mix the return value and the success/fail. In MFC/C++, I'd do that as a function that returned a BOOL, indicating whether it worked or not, and a reference to a CString as a parameter.

[Judah Gabriel Himango]

String.Empty is in the .NET framework

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

[Nish Nishant]

Chris Losinger wrote:

C++ doesn't have String.Empty.

It does if you turn on /clr - and then you have String::Empty :rolleyes:

Regards, Nish

---

Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
Currently working on C++/CLI in Action for Manning Publications. Also visit the Ultimate Toolbox blog (New)

[Zac Howland]

Chris Losinger wrote:

C++ doesn't have String.Empty.

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

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

[Douglas Troy]

Not sure it matters, since you can just use the following check:

if (!string.IsNullOrEmpty(MyReturnStringValue)) 
{ 
    ... 
}

But I generally return empty strings ...

---

:..::. Douglas H. Troy ::..
Bad Astronomy |VCF|wxWidgets|WTL

[Judah Gabriel Himango]

If the function truely failed, that's what exceptions are for. If the function has functioned properly (has not failed) but the there is no result, that's when you return null. Say you had a function like this: public string GetNodeTextAtIndex(int index) { ... } If the function fails for any reason (say, bad input, maybe specifying a negative number as the index), then you throw an exception. If the function otherwise succeeds, but doesn't find any node at that index, you return null.

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

[Kevin McFarlane]

If the method actually fails then throwing an exception is appropriate. But if the method doesn't fail then returning String.Empty or null could be valid depending on the context. However, in general, I like to interpret null as either "not initialised" or indicative of an error. Ideally the source code should describe exactly what it means when it returns an empty string or or a null.

Kevin

[Colin Angus Mackay]

It depends. It may be valid to return an empty string, in which case you can't use it to signify a failure, in which case null is the best option.

---

Upcoming Scottish Developers events: * UK Security Evangelists On Tour (2nd November, Edinburgh) * Developer Day Scotland: are you interested in speaking or attending? My: Website | Blog

[Anish M]

May be null, but for sure not an Empty String

[led mike]

Chris Maunder wrote:

and that function fails

Based on the responses so far you need to define "fails". IMHO failure indicates an exceptional condition and therefore an exception should be thrown. However if you are referring to a valid outcome of an operation I would likely choose null over an empty string for two reasons: 1) it is more efficient 2) Since the caller must "check" the return value to determine the outcome, it is part of the contract and documented, and therefore is not significant in ways other than efficiency.

led mike

[Kevin McFarlane]

Good summary, Judah.:)

Kevin

[Nemanja Trifunovic]

Judah Himango wrote:

String.Empty is in the .NET framework

I know that. I usually don't criticize things I don't know :) [EDIT} So you answered to Chris L. not me. Another CP forum joke[/EDIT]

Programming Blog utf8-cpp

[Nemanja Trifunovic]

Dario Solera wrote:

It could be correct, if the method actually fails.

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

Programming Blog utf8-cpp

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