меня тут волнует только этическая сторона, был бы другой вариант - я б нашел его

А, ты Try монадку переизобретаешь, я понял

🤦‍♂️ты опять ничего не понял

Как объяснил

давай еще раз задачу опишу

Сначала посмотри https://github.com/jasongoodwin/better-java-monads/blob/master/src/main/java/com/jasongoodwin/monads/Try.java

ты что-то универсальное пытаешься запилить?
я пока подумал что проблема только в том что тебе ваши методы в лямбды совать неудобно потому что они все что-то throws.
но походу я тоже не понял задачу.

Видимо нужен искуственный контекст вокруг метода, чтоб потом среагировать на результат его выполнения. Видимо велосипед > АОП

Дано:
апи метод:

public void bla() throws RemoteException, CheckedException {}

и вызов этого метода:

void m()  throws RemoteException, CheckedException {
    bla()
}

Что я хочу получить на выходе:

void m()  throws RemoteException, CheckedException {
    withAudit(A::bla).onSucc((l, v) -> l.onBla(v)).onFail(System.out::println).execute();
}

Ограничения:
1. Сохранение типов эксепшенов, то есть если bla бросает RemoteException, то и m должен отдать тот же эксепшен
2. Нельзя модифицировать код вокруг m
3. Нельзя модифицировать код внутри bla
4. В случае если bla бросил эксепшен, onFail должен гарантированно вызваться, а execute бросить эксепшен брошенный bla

Что я сделал:
Я "обманываю" компилятор используя определение throw из спецификации, таким образом, что бы с позиции компилятора чекедэксепшен представлял собой RuntimeExcption, но! при этом реальный тип сохраняется(возможно благодаря тому, что JVM не различает чекед и не чекед эксепшены, ограничение на уровне компилятора), у этого подхода заметный минус в том, что чекед эксепшены становятся как бы "неявны"

Почему не подходят монада Try:
потому что это "монада", сохранить тип не получиться без сильных приседаний

Почему не АОП:
потому что аоп это лишнее усложнение

в моем кусочке все понятно, меня волнует только этическая сторона вопроса, больше ничего. мне завтра это решение либо защищать либо нет

Пример:

    int t1() throws RemoteException {
        return 0;
    }

    void test() {
        Integer done = withAudit(() -> t1()).onSuccess((l, s) -> System.out.println()).execute();
    }

Ну, с этической точки зрения я подобный хак уже в либах видел, иногда единственный выход. С другой стороны чейн вызовов на ровном месте + явный execute как-то не айс как по мне

У тебя в одном чейне может быть выброшено несколько разных эксепшнов и ты хочешь сохранить их тип - думаю для этого хак норм, тайпсейф тут вряд ли прокатит

допустим от execute можно избавиться, он тут лишний. а чем чейн плох?

Чейн может перерасти во fluent фигню, которую потом устанешь читать

альтернативы тут мега контекст только.

наверное

Плюс что будет с кейсом, когда мне надо onSuccess трансформировать результат, а тот метод также кидает Exception?

нееее, так низя делать, onSuccess не может модифицировать результат, так как может только аудировать