Will New Return Null in Any Case

Will new return NULL in any case?

VC6 was non-compliant by default in this regard. VC6's new returned 0 (or NULL).

Here's Microsoft's KB Article on this issue along with their suggested workaround using a custom new handler:

• Operator new does not throw a bad_alloc exception on failure in Visual C++

If you have old code that was written for VC6 behavior, you can get that same behavior with newer MSVC compilers (something like 7.0 and later) by linking in a object file named nothrownew.obj. There's actually a fairly complicated set of rules in the 7.0 and 7.1 compilers (VS2002 and VS2003) to determine whether they defaulted to non-throwing or throwing new.

It seems that MS cleaned this up in 8.0 (VS2005)—now it always defaults to a throwing new unless you specifically link to nothrownew.obj.

Note that you can specify that you want new to return 0 instead of throwing std::bad_alloc using the std::nothrow parameter:

SomeType *p = new(std::nothrow) SomeType;

This appears to work in VC6, so it could be a way to more or less mechanically fix the code to work the same with all compilers so you don't have to rework existing error handling.

Will new operator return NULL?

On a standards-conforming C++ implementation, no. The ordinary form of new will never return NULL; if allocation fails, a std::bad_alloc exception will be thrown (the new (nothrow) form does not throw exceptions, and will return NULL if allocation fails).

On some older C++ compilers (especially those that were released before the language was standardized) or in situations where exceptions are explicitly disabled (for example, perhaps some compilers for embedded systems), new may return NULL on failure. Compilers that do this do not conform to the C++ standard.

SQL group by return null if one is null

You can use a case expression to return the latest deleted where all records are deleted, and where any are NULL the expression will return NULL:

SELECT order_number, 
        CASE WHEN COUNT(*) = COUNT(date_deleted) THEN MAX(date_Deleted) END AS date_deleted
FROM orders 
GROUP BY order_number;

You may also wish to return the earliest deleted date with MIN(date_deleted), the point is though, if you group by order_number you can only return one date_deleted and you have to tell the query engine which one you want to return by using some kind of additional logic like MIN or MAX.

Can anyone tell me why my case statement return null(good)

When where statement gets null values, then it returns unknown, which ecludes record from resultset.

Read more about three valued logic in SQL Server (just google it :) ).

This is why you don't get any records. For example, comapring to a column, where a is always null, gives you no records in rsult.

You need to use coalesce or similair "null-preventing" functions.

How to avoid return null on my case?

Use a local variable and assign it and return at the end of the method and you can use jumping statements in your code if it can improve the performance

public Date getNextDay(){
            Date date = new Date();
            try {
                if(day < getMaxDaysInMonth()){
                    date= new Date(day + 1, month, year);
                }
                else if(day == getMaxDaysInMonth() & month < 12){
                    date = new Date(1, month+1, year);
                }
                else if(day == getMaxDaysInMonth() & month == 12){
                    date = new Date(1, 1, year+1);
                }
            } catch (Exception e) {
                System.out.println("You have entered an invalid Date.");
                e.printStackTrace();

            }
            return date;
        }

what is different between return null and throw exception?

Normally, throwing an exception is superior because it is considerably more informative than returning null, and because calling code can’t just blithely ignore the returned value in a way that leads to a subsequent and uninformative NullPointerException.

However, the documentation for onBind explicitly says that it’s okay to return null. Since that’s how the API is designed, it makes more sense to return null in this particular case than to throw an exception.

In general, throwing an exception is better, because it prevents calling code from assuming it’s okay to continue as if the operation succeeded when it did not in fact succeed. But in this case, the method is actually supposed to return null when the operation is not supported (which in my opinion is not a good design decision).

C# - Does FirstOrDefault() return null in this case?

If in your query

(from result in DB.ContextManagement.ResultTable
                        where result.FinaName.compareTo(fileName) == 0
                        select result)

no entity respect your condition then the FirstOrDefault will return null.

It is specified in the documentation

"Remarks
The default value for reference and nullable types is null."

Since the type of result is a reference type it will return null.

---

Related Topics