Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

[AssistedInject] Validate that parameters names match between factory method and the constructor

See original GitHub issue

With the following code:

package com.example

import dagger.Component
import dagger.assisted.Assisted
import dagger.assisted.AssistedFactory
import dagger.assisted.AssistedInject

class NamingRepro @AssistedInject constructor(
    @Assisted private val foo: String,
    @Assisted private val bar: String,
) {

    interface Factory {
        fun create(
            bar: String,
            foo: String
        ): NamingRepro

    fun print() {
            Passed foo: $foo,
            passed bar: $bar

interface NamingComponent {

    fun repro(): NamingRepro.Factory

Dagger will ignore the fact that foo and bar parameters order is different in the create method and the constructor. The generated factory will then pass arguments from create to the constructor in unexpected (or expected, but clearly not intentional) order. So:

    .create(bar = "bar", foo = "foo")

will print

Passed foo: bar,
passed bar: foo

This is error prone and difficult to prevent using automated tools. It would be great if Dagger verified the parameters names as well, requiring them to match between the factory method and the constructor.

Also as far as I understand, square/AssistedInject doesn’t verify the parameters order, but forces matching names (if there were more than one parameter with the same type). This can lead to some confusing migration errors, as now the behavior is the opposite.

Issue Analytics

  • State:closed
  • Created 3 years ago
  • Reactions:2
  • Comments:16 (4 by maintainers)

github_iconTop GitHub Comments

IlyaGulyacommented, Jan 26, 2021

Aren’t qualifiers more natural for Dagger than some custom parameter for @Assisted annotation? In this case, it would be much more flexible. Those who want to use String constants to disambiguate the types could use the @Named qualifier in this case. And those who like a more declarative (IMO) way of using custom qualifiers would not need to switch to String constants. Also, switch to assisted injection for existing classes would be much easier if qualifiers already there.

tbroyercommented, Jan 20, 2021
Read more comments on GitHub >

github_iconTop Results From Across the Web

Using @Assisted inject with multiple params of same Type ...
The types of the factory method's parameters must be distinct. To use multiple parameters of the same type, use a named @Assisted annotation...
Read more >
Assisted Injection - Dagger
A factory is typically responsible for combining all of the parameters and creating the object. (Related: guice/AssistedInject). Dagger assisted injection. To ...
Read more >
Assisted Injection for Dagger - Google Groups
You use @Assisted annotations to match factory method parameters to the ... "field injection" of parameters and to disambiguate quickly in the constructor ......
Read more >
AssistedInject is dead, long live AssistedInject!
There is one pattern to watch out for in this migration. Dagger's assisted injection requires that the factory return type matches the type ......
Read more >
Bug patterns
The called constructor accepts a parameter with the same name and type as one ... Scope annotation on implementation class of AssistedInject factory...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found