Zwracanie pustego obiektu

Cześć, jak najlepiej obsłużylibyście taki scenariusz, że jeśli wyciągamy z bazy encję za pomocą findOne i ona jest nullem, bo akurat nie znalazło żadnego wiersza to nie dostajemy na wyjściu w potrzebnym miejscu nulla tylko tą encję jpa, ale z nullowymi polami ?

Może być coś takiego ? :

protected <T>T getOrEmpty(T obj, Class<T> clazz) {
        try {
            return Optional.ofNullable(obj).orElse(clazz.newInstance());
        } catch (InstantiationException | IllegalAccessException e) {
            e.printStackTrace();
            throw new IllegalArgumentException("Fail with init empty object");
        }
    }

i dalej..

AnyEntity e = getOrEmpty(repo.findOne(2L));
assembler.toDto(e);

Czy to jest zły pomysł i są lepsze ?

A czemu nie zwrócić optionala?

No mogę zwrócić optionala, ale co ja potem zrobię z tym optionalem ?
Wymagania frontu są takie, że jeśli nie ma danej encji w bazie to nie zwracam nulla tylko pustego dtosa ..

Jest taki wzorzec nawet: https://sourcemaking.com/design_patterns/null_object

@Markuz: Wzorce projektowe odnoszą się do programowanie obiektowego, a nie w proceduralnego w Pascalu. Autor wyraźnie pisze o DTO, a nie obiekcie z zachowaniem. Czyli NullObject tutaj nie pomoże. DTO / Struktury to nie obiekty...

Optional nie został stworzony po to, by go tworzyć i od razu odpakowywać.
Jak front ma wymagania, to niech sobie je zakoduje. I gdy API zwróci im 404 Not Found to niech sobie zrobią pusty obiekt, Ty natomiast zwracaj 404.

Pomysł jest dostosowany to głupoty wymagań. Jak front chce dostawać granaty bez zawleczki do dalszej zabawy - to może nie powinieneś ich pozbawiać tej przyjemności.
Nie rozumiem, ale nie widze jakiegoś lepszego wyjścia.

Ja bym zadał pytanie od drugiej strony - czy spotkaliście się z sensownym użyciem null objecta?
Z pominięciem kontenerów / kolekcji.