yuliskov/SmartTube · error · UnsupportedOperationException

Somehow we couldn't create the ViewHolder for message. Pleas

Error message

Somehow we couldn't create the ViewHolder for message. Please, report this issue on GitHub with full stacktrace in description.

What it means

getHolder instantiates your holder class reflectively: it first tries the public (View, Object) constructor for payload support, falls back to (View), then applies the style. Any failure — missing both constructors, non-public or abstract class, non-static inner class, or an exception thrown inside the constructor — is wrapped in UnsupportedOperationException whose cause holds the real error. Diagnose from the caused-by chain, not the wrapper text.

Source

Thrown at chatkit/src/main/java/com/stfalcon/chatkit/messages/MessageHolders.java:648

        View v = LayoutInflater.from(parent.getContext()).inflate(layout, parent, false);
        try {
            Constructor<HOLDER> constructor = null;
            HOLDER holder;
            try {
                constructor = holderClass.getDeclaredConstructor(View.class, Object.class);
                constructor.setAccessible(true);
                holder = constructor.newInstance(v, payload);
            } catch (NoSuchMethodException e) {
                constructor = holderClass.getDeclaredConstructor(View.class);
                constructor.setAccessible(true);
                holder = constructor.newInstance(v);
            }
            if (holder instanceof DefaultMessageViewHolder && style != null) {
                ((DefaultMessageViewHolder) holder).applyStyle(style);
            }
            return holder;
        } catch (Exception e) {
            throw new UnsupportedOperationException("Somehow we couldn't create the ViewHolder for message. Please, report this issue on GitHub with full stacktrace in description.", e);
        }
    }

    @SuppressWarnings("unchecked")
    private short getContentViewType(IMessage message) {
        if (message instanceof MessageContentType.Image
                && ((MessageContentType.Image) message).getImageUrl() != null) {
            return VIEW_TYPE_IMAGE_MESSAGE;
        }

        // other default types will be here

        if (message instanceof MessageContentType) {
            for (int i = 0; i < customContentTypes.size(); i++) {
                ContentTypeConfig config = customContentTypes.get(i);
                if (contentChecker == null) {
                    throw new IllegalArgumentException("ContentChecker cannot be null when using custom content types!");
                }

View on GitHub (pinned to 3de8d90593)

Solutions

Read the caused-by exception: NoSuchMethodException means a missing constructor, InstantiationException means abstract/non-instantiable, InvocationTargetException means the constructor itself threw
Declare public MyHolder(View view) { super(view); } and, when registering a payload, public MyHolder(View view, Object payload) { this(view); ... }
Make nested holder classes public static and register the concrete class, never an abstract one
Verify the layout resource passed at registration matches the views the constructor expects

Example fix

// before
class CustomHolder extends BaseMessageViewHolder<CustomMsg> {
    CustomHolder(View v) { super(v); } // package-private, no payload constructor
}

// after
public class CustomHolder extends BaseMessageViewHolder<CustomMsg> {
    public CustomHolder(View v) { super(v); }
    public CustomHolder(View v, Object payload) { this(v); initPayload(payload); }
}

Defensive patterns

Strategy: validation

Validate before calling

// Fail fast at registration instead of during layout:
try {
    holderClass.getDeclaredConstructor(View.class, Object.class);
    holderClass.getDeclaredConstructor(View.class);
} catch (NoSuchMethodException e) {
    throw new IllegalStateException(holderClass.getSimpleName() + " needs public (View) and (View, Object) constructors", e);
}

Prevention

Always declare public (View) and, when using payloads, public (View, Object) constructors on custom holders
Make nested holder classes public static and register concrete classes only
Smoke-test one bind of each custom type in debug builds to surface reflection failures early

When it happens

Trigger: Registering a custom holder without a public BaseMessageViewHolder(View) (and (View, Object) when payloads are registered) constructor; registering an abstract base holder class instead of the concrete subclass; a non-static inner holder class whose implicit outer reference breaks the constructor signature; findViewById/cast failing inside the constructor because the wrong layout resource was registered.

Common situations: Writing a first custom content-type holder in Kotlin where the class or constructor is not public; passing the wrong item layout to registerContentType so constructor view lookups fail; R8/ProGuard renaming in release builds of classes referenced only reflectively.

Related errors

AI-assisted analysis of yuliskov/SmartTube@3de8d90593 (2026-08-22). Data as JSON: /api/errors/22c2e30e8c25dfe6. Report an issue: GitHub.