Our website uses cookies to enhance your browsing experience.
Accept
to the top
close form

Fill out the form in 2 simple steps below:

Your contact information:

Step 1
Congratulations! This is your promo code!

Desired license type:

Step 2
Team license
Enterprise license
** By clicking this button you agree to our Privacy Policy statement
close form
Request our prices
New License
License Renewal
--Select currency--
USD
EUR
* By clicking this button you agree to our Privacy Policy statement

close form
Free PVS‑Studio license for Microsoft MVP specialists
* By clicking this button you agree to our Privacy Policy statement

close form
To get the licence for your open-source project, please fill out this form
* By clicking this button you agree to our Privacy Policy statement

close form
I am interested to try it on the platforms:
* By clicking this button you agree to our Privacy Policy statement

close form
check circle
Message submitted.

Your message has been sent. We will email you at


If you haven't received our response, please do the following:
check your Spam/Junk folder and click the "Not Spam" button for our message.
This way, you won't miss messages from our team in the future.

>
>
>
V3125. The object was used after it was…
menu mobile close menu
Analyzer diagnostics
General Analysis (C++)
General Analysis (C#)
General Analysis (Java)
Micro-Optimizations (C++)
Diagnosis of 64-bit errors (Viva64, C++)
Customer specific requests (C++)
MISRA errors
AUTOSAR errors
OWASP errors (C#)
Problems related to code analyzer
Additional information
toggle menu Contents

V3125. The object was used after it was verified against null. Check lines: N1, N2.

Dec 08 2016

The analyzer detected a possible error that may lead to a null dereference.

The following situation was detected. An object is tested for 'null' first and then used without such a check. It implies one of the two scenarios:

1) An exception will be thrown if the object turns out to be null.

2) The program runs correctly all the time, as the object is never null, and the check is therefore unnecessary.

The first scenario is illustrated by the following example, where an exception is likely to be thrown.

obj = Foo();
if (obj != null)
  obj.Func1();
obj.Func2();

If the 'obj' object turns out to be null, evaluating the 'obj.Func2()' expression will result in an exception. The analyzer displays a warning on this code, mentioning 2 lines. The first line is where the object is used; the second is where it is tested for 'null'.

Fixed code:

obj = Foo();
if (obj != null) {
  obj.Func1();
  obj.Func2();
}

The second scenario is illustrated by the following example. The list is iterated in a safe way, so the check can be omitted:

List<string> list = CreateNotEmptyList();
if (list == null || list.Count == 0) { .... }
  foreach (string item in list) { .... }

This code works properly all the time. The 'list' list is never empty. However, the analyzer failed to figure this out and produced a warning. To remove the warning, delete the "if (list == null || list.Count == 0)" check: this operation is meaningless and may confuse the programmer who will be maintaining the code.

Fixed code:

List<string> list = CreateNotEmptyList();
foreach (string item in list) { .... }

Another case where analyzer generates warning is when the null check and the variable's use are situated in the different branches of if\else or switch sections. For example:

if (lines.Count == 1)
{
    if (obj != null)
        obj.Func1();
}
else
{
    lines.Clear();
    obj.Func2();
}

In this case, despite the fact that both branches will not be executed simultaneously - only one branch will be selected for the execution, the null check in one of them indirectly indicates a possibility of a variable receiving null value in other branch as well. Therefore, if control flows to that branch, exception will be generated.

Corrected variant:

if (lines.Count == 1)
{
    if (obj != null)
        obj.Func1();
}
else
{
    lines.Clear();
    if (obj != null)
        obj.Func2();
}

Instead of changing the code, you can add a special comment to suppress false warnings. For the example above, you would have to use the following comment: "obj.Foo(); //-V3125".

This diagnostic is classified as:

You can look at examples of errors detected by the V3125 diagnostic.