Stupid question 40: Should I return 'null' or throw an exception if a methods fails to produce requested value?

I'd say you nailed it with your " If null would be considered an error, then I should have used an exception instead." comment. 

Basically, you shouldn't be returning error codes. You should be throwing exceptions. 

It depends on how important the return value is to your programme.
If the programme can continue, then I would return the null value, making
sure the user is aware of any lack of functionality due to the null value.

If the value of null hinders the functionality then produce the exception
and give the user clear instructions on how they can (if possible) rescue the situation. 

You could do return throw HTFDidYouDoThatException() 

:)

It depends on where it sits in the layer, if it's below the UI layer then i'd expect some hard returns as in the end testing for nulls can be a pain all the time especially when you assume or infer that a result would come back. That way you can also bubble the error higher up in the call stack to see if it was data being passed in that passed compile time & runtime checks but had semantic issues (ie business logic related). 

Beyond the very academic answers you'll probably get about exceptions being expensive (I say academic, because, well, exceptions should be an exception!) there's a fundamental semantic difference. An exception is almost always an indication of "Hey, something went wrong" whilst a null can well be an indication that everything ran just fine but there was simply no value to return. If you call into your data repository and the thing is offline, great, that's an exception. If you call into it and the desired item doesn't exist, a null result says "Everything worked, but I have nothing for you".

Just because you're absolutely positive a value should exist today, doesn't mean it will tomorrow. Then again, if you proceed with that exception then sooner or later you'll get an exception somewhere anyway! :) 

In some cases, you might also use the Null Object Pattern (http://en.wikipedia.org/wiki/Null_Object_pattern) to handle a null. 

public interface Animal {
        void makeSound();
}
 
public class Dog implements Animal {
        public void makeSound() {
                Console.WriteLine("woof!");
        }
}
 
public class NullAnimal implements Animal {
        public void makeSound() {
        }
}
 

This problem boils down to the fact that your component/method/etc (ignoring side effects) can possibly return a number of different values, and might even fail for a number of different reasons (which might need to be handled differently), and that you are returning but a single value with the output state/outcomes being implicit in the result.

Personally I feel that nulls are bad to begin with as they essentially are an escape hatch from the type system, and a 'unit' or even empty value would almost invariably be a better choice but anyway.

I found that this problem is also related to one i've seen with an overuse of bools.
Essentially you are wanting two values to be returned : the value that you are interested in - such as the json string, new type etc. and a second value which informs you of the resultant state of the operation. 

The problem with the use of bool to denote resultant outcome is entirely that it is limited to two arbitrarily assigned values. it is possibly and reasonable to return a custom enum in this case to denote which of the possible outcomes it has been. ( or in the case of something like F# to use the more elegant option of discriminated unions ).

It might well be that an empty value of your given type is an appropriate response, and the outcome is implicit. 
The other option is to use exceptions; which can be provided in whatever flavors that you choose for them : and gives the rest of the system a fighting chance of knowing what the possible thing that happened that caused your method to return an empty value.

At the end of the day, the option is open to you to your choice, but by specifying the possible outcomes of your methods; it may take more time to reason about them, but from personal experience, every time I've done this, i've found that my code has been much more robust and i cannot recall having to go back and fix bugs in it, as by leaning on the type system, the compiler has taken care of those problems for me.

As an aside, you'll also notice that HTTP in it's own right works in this manner; having both the response and status code to denote the outcome of the operation requested upon it. 

A third option is to turn it into a TryX method that returns a bool and has an out parameter for the return result. This allows you to communicate the success/failure along with the result. Depending on the situation, null may be a valid result.

Is a failure something the calling code can handle? Is it something the calling code is expected to handle? The Try method signature helps communicate that this can fail and we expect you to handle that possibility. 

Or you can write methods like, bool TryGetSomething(out something) where the return indicates failure and the out param is the result if it succeeded. The pattern is used elsewhere in the .NET Framework (TryParse).

Edit: Ahhh, Mike beat me. :( 

@mike @kunikos - sorry if mine was a bit tl;dr for you. it describes this approach and goes into more details as to why you may or may not want to use booleans as your status code. 

I use both nulls and exceptions depending on the level of the problem.  Consider a method, Person.GetAge().   The obvious return value would be an int (or perhaps a decimal or TimeSpan), but they all assume that you have the information available.  But you may not have the person birthday.  Hence null would be appropriate for "I don't know".   On the other hand, if trying to get the value lead to a database connection error, that would get an exception. 

@James Tyrand - I read your post after I had posted mine and you definitely covered it better. Unfortunately I wasn't fast enough to update my post like kunikos did. I especially like the idea of returning an enum result to communicate where things went wrong. 

No one mentioned "Maybe" Monad.

http://smellegantcode.wordpress.com/2008/12/11/the-maybe-monad-in-c/