null vs String.Empty

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

[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