Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mixing Indexed and Named Arguments throw a NullReferenceException #614

Open
Curlack opened this issue Jul 28, 2021 · 2 comments
Open

Mixing Indexed and Named Arguments throw a NullReferenceException #614

Curlack opened this issue Jul 28, 2021 · 2 comments

Comments

@Curlack
Copy link
Contributor

Curlack commented Jul 28, 2021

select 1 where @0 = @condition
@0 = null
@condition = 1

I'm using db.FetchAsync(cancellationToken, sql, args) method

For the second parameter, PetaPoco will iterate through all arguments to find an object with the name "Condition". Problem is that @0 is null and null.GetType() throws the exception.

Suggestions:
Using the null-condition operator e.g. o?.GetType()
of filter the null values before iterating e.g. foreach (var o in args_src.Where(o => o != null))

The issue is in the ParametersHelper line 57 under the comment "Look for a property on one of the argument with this name"

@asherber
Copy link
Collaborator

Note that the same exception can be thrown, legitimately, even without indexed arguments.

ObjectWithConditionProperty myObj = null;
db.Fetch<object>("select 1 where Foo = @condition", myObj);

If we change the loop so that we ignore any args which are null, the above code would throw a different exception. Which exception better describes what's going on? The object I passed in does have a condition property, but the instance is null.

@Curlack
Copy link
Contributor Author

Curlack commented Jul 29, 2021

I see what you mean, but the way I'm passing named arguments is new { name = value } i.e. always using an instance.
Maybe ignoring nulls using the null-condition operator and modifying the exception to include both causes e.g. Parameter '{0}' specified but couldn't be found. Either it's missing, misspelled or has a null reference.\r\n{1}
The code shouldn't fail the moment it can't determine the type. It should complete the args scan and only fail based when !found.
I think it's fair to say that named arguments must always be object wrappers of indexed arguments i.e. always have an instance with at least one property of some supported type. From what I can see, the supported type are only types that can resolve their value to string and enumerables of those types.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants