Should a Function Use: Return Null;

Should a function use: return null;?

If you don't return anything, just use return; or omit it at all at the end of the function.

If your function is usually returns something but doesn't for some reason, return null; is the way to go.

That's similar to how you do it e.g. in C: If your function doesn't return things, it's void, otherwise it often return either a valid pointer or NULL.

Should functions return null or an empty object?

Returning null is usually the best idea if you intend to indicate that no data is available.

An empty object implies data has been returned, whereas returning null clearly indicates that nothing has been returned.

Additionally, returning a null will result in a null exception if you attempt to access members in the object, which can be useful for highlighting buggy code - attempting to access a member of nothing makes no sense. Accessing members of an empty object will not fail meaning bugs can go undiscovered.

Should I avoid returning null in my java function?

You should take a look at the Optional class!

Make your method return type Optional<EArea> and simply return Optional.ofNullable(existingArea) you will have to slightly modify your Code but the benefits of Optional are really worth it!

Is it better to return `undefined` or `null` from a javascript function?

I will argue there is no best way, and even standard functions sometimes choose one or the other.

For example:

[[Prototype]]
Ordinary objects have a [[Prototype]] internal slot, which determines from which other object they inherit from. Of course, there must be a way to say that an object does not inherit from any other one. In this case, "there is no such object" is represented using null.
Object.getOwnPropertyDescriptor
It is expected to return a property descriptor, that is, an object which describes a property (e.g. value, writability, enumerability and configurability). However, the property may not exist. In this case, "there is no such property" is represented using undefined.
document.getElementById
It is expected to return the element with the given ID. However, there might be no element with that ID. In this case, "there is no such element" is represented using null.

So just choose whatever you prefer or think makes more sense for your specific case.

Is returning null bad design?

The rationale behind not returning null is that you do not have to check for it and hence your code does not need to follow a different path based on the return value. You might want to check out the Null Object Pattern which provides more information on this.

For example, if I were to define a method in Java that returned a Collection I would typically prefer to return an empty collection (i.e. Collections.emptyList()) rather than null as it means my client code is cleaner; e.g.

Collection<? extends Item> c = getItems(); // Will never return null.

for (Item item : c) { // Will not enter the loop if c is empty.
  // Process item.
}

... which is cleaner than:

Collection<? extends Item> c = getItems(); // Could potentially return null.

// Two possible code paths now so harder to test.
if (c != null) {
  for (Item item : c) {
    // Process item.
  }
}

don't return null -- what to return for search function

Throwing an exception is an expensive operation, since there is a context switch and a lot of debug information has to be gathered, so you want to avoid throwing them as a way to control process flow (especially if you can handle the situation without throwing exceptions). Returning a null can be perfectly acceptable in order to avoid catching exceptions.

An example of this in action would be a couple of LINQ functions in C#. These methods can return a null:

SingleOrDefault(); // returns a single instance of an object, or null if not found

FirstOrDefault(); // returns the first matching object, or null if not found

This allows you to check for null without trying to figure out control flow using exception handling.

One exception (pardon the pun) that I can think of is using exceptions to communicate across program boundries. If you had, for example, a data access layer in a separate DLL, and you needed to communicate a database failure back to the parent program, sometimes the best way to do that is through exception handling.

why this function returns null?

The following line allocates memory space in the stack but after the function ends everything is gone:

char result[1000];

You need to allocate memory in the heap like that:

char *result = malloc(sizeof(char) *1000);

Note: don't forget to free that memory space by free function.

Why do I need to return null for functions with nullable return type?

It's a warning, not an error. Warnings are for things that are technically legal but very likely are programming mistakes. It's much more likely that someone writing that code forgot to handle a code path than it is that they intentionally wanted an implicit return null. An explicit return null additionally makes intent clear and thus is more readable.

Should a Function Use: Return Null;