Pytanie o poprawność rozwiązania

Mam pytanie dotyczące tzw. programowania na wyjątkach.

Chodzi mi o coś takiego:

Mam klasę MyKlazz, której obiekty mogę wysyłać za pomocą klasy z zewnętrznej biblioteki, za pomocą metody:

public class KlazzProcessor {

public void send(MyKlazz objectToSend) throws KlazzSendException {...}
}

I teraz mam drugą klasę, np KlazzFixer.fix(MyKlazz objectToFix), która może naprawić dane obiekty.

I teraz pytanie:
Czy coś takiego:

public void sendAndFixKlazz(MyKlazz objectToSend){
	KlazzProcessor kp = new KlazzProcessor();
	KlazzFixer kf = new KlazzFixer();

	try {
		kp.send(objectToSend);
	} catch ( KlazzSendException kse){
		kf.fix(objectToSend);
		kp.send(objectToSend);
	}
}

jest dopuszczalne? Pytam bo w wielu miejscach czytało się raczej różne rzeczy o programowaniu na wyjątkach.

Co znaczy "czy jest dopuszczalne"? Czy można tak napisać? Można, pytanie czy warto. Obsługa wyjątków jest kosztowna. Nie da się sprawdzić czy obiekt wymaga fixowania czy też nie, bez konieczności próby wysłania i łapania wyjątku?
Bo wyjątki powinny służyć do obsługi sytuacji wyjątkowych, a nie to zwykłego sterowania przepływem.

To drugie wywolanie moze znowu wywolac wyjatek, prawda? Czy jest to niemozliwe, ze po fix moze nastapic wyjatek? Jesli moze, to powinienes to zrobic w petli.
Dodatkowo, jesli wyjatek jest 'checked' (dziedziczy po Exception, nie po RuntimeException) to kompilator wymysi na tobie w przypadku ktory podales, ze metoda zawierajaca ten kod tak bedzie musiala ten wyjatek deklarowac. Jesli po fix nie ma mozliwosci zeby wyjatek zostal rzucony, to ta deklaracja zsmieci kod poniewaz bedzie mowila ze moze byc wyjatek ktorego nie moze byc ;d

Już tłumaczę:

Obiekty klasy MyKlazz są duże. Sprawdzenie ich poprawności kosztuje sporo - raczej procka niż pamięci, ale jednak sporo - i to generalnie właśnie to jest powodem, że próbuję łapać wyjątki.

Co do drugiego pytania: cała procedura naprawy obiektów wygląda tak, że mam możliwość sprawdzenia, czy obiekt jest prawidłowy i czy jest naprawialny. Tyle, że to naprawdę potrafi sporo czasu zabrać (wewnątrz obiektów są listy obiektów, które zawierają listy obiektów, które zawierają listy obiektów itp.), natomiast odpowiedź z serwera - który tak naprawdę niczym innym się nie zajmuje tylko przyjmowaniem obiektów - przychodzi dużo szybciej.

To, co w tej chwili robimy nie jest czymś samodzielnym, raczej częścią większej całości (której tutaj raczej podać nie mogę). Wygląda to po prostu mniej więcej tak, że otrzymujemy na wejściu z jednego serwera gotowe paczki danych, które służą nam do uruchomienia konkretnego procesu (w międzyczasie są nieco zmieniane), i które lecą dalej.

Problem w tym, że ok. 5% danych na wejściu jest wadliwe, tzn serwer docelowy nie obsługuje ich - i trzeba je poprawiać. Samo sprawdzenie poprawności obiektu jest czasochłonne (ok 1-3 sekund na obiekt, co przy większych ilościach jest czasem zbyt długim), naprawa jeszcze dłuższa (od 10 do 25 sekund).

Muszę przyznać, że o ile podaną wyżej konstrukcję sam wymyśliłem, to mam opory natury estetycznej, gdyż to jakoś dziwnie, według mnie, wygląda.

Ok, jeśli to faktycznie tyle trwa to stosowanie happy-case scenario jest dobrym rozwiązaniem.