try with resources

Cześć.
Stworzyłem customową klasę try with resources poprzez implementację interfejsu Closeable.
Wykorzystuję ją do czytania plików CSV różnych rodzajów, zaleznie od pliku wykonuje inne operacje (walidację, tworzenie xml'a itp), pytanie co z zapisem do bazy i innymi ? robić to pod tym samym interfejsem co walidacja i tworzenie xml'a ? czy zwracać obiekt walidacji z errorami i zwracam xml w byte i obsługiwać to poza blokiem try with resources?

Przykład:

try(CSVReaderInterface reader : new CustomReaserClass(reader)) {
       reader.deletePreviousUpload();
       reader.validate().sendEmailWithErrors();
       reader.generateXml();
       reader.saveToDatabase();
      ...
}

czy coś w tym stylu

deletePreviousUpload();
try(CSVReaderInterface reader : new CustomReaserClass(reader)) {
       Validator validator = reader.validate();
       byte[] xml = reader.generateXml();
      ...
}

sentEmail(validator.getErrors(), to);
saveToDatabase(xml);

Ogólnie chodzi o to czy warto wszystko co chcemy zrobić na pliku obsługiwanym przez CustomReaserClass ma być pod jednym interejsem?

Jedyne co robi try with resources to wywołuje funkcje close(), niezależnie od tego czy poleciał wyjątek czy nie.Nie rózni się niczym od try/finally gdzie w finally jest .close().

TomRiddle napisał(a):

Jedyne co robi try with resources to wywołuje funkcje close(), niezależnie od tego czy poleciał wyjątek czy nie.Nie rózni się niczym od try/finally gdzie w finally jest .close().

Różni się :] https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html - suppressed exceptions. Jeśli poleci exception zarówno w bloku try jak i w metodzie close przy zamykaniu zasobu to zwykłe try/finally zwróci wyjątek z metody close, a try-with-resources zwróci wyjątek z bloku try. Tak to przynajmniej dla mnie wygląda - nie sprawdzałem tego.

Wibowit napisał(a):

TomRiddle napisał(a):

Jedyne co robi try with resources to wywołuje funkcje close(), niezależnie od tego czy poleciał wyjątek czy nie.Nie rózni się niczym od try/finally gdzie w finally jest .close().

Różni się :] https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html - suppressed exceptions. Jeśli poleci exception zarówno w bloku try jak i w metodzie close przy zamykaniu zasobu to zwykłe try/finally zwróci wyjątek z metody close, a try-with-resources zwróci wyjątek z bloku try. Tak to przynajmniej dla mnie wygląda - nie sprawdzałem tego.

Na to wygląda.

No więc try-with-resources to to samo co try/catch (e), gdzie w catch jest .close() oraz throw e;

Z tego co zrozumiałem chodzi Ci o to, czy w interfejsie CSVReaderInterface zawrzeć funkcjonalności:

• deletePreviousUpload
• sendEmailWithErrors
• saveToDatabase

Moim zdaniem, wysyłkę email powinien realizować EmailService natomiast zapis do bazy to odpowiedzialność Repository.
Niech CSVReaderInterface realizuje funkcje z odczytem plików CSV. Inne funkcjonalności pozostaw dla innych interfejsów, klas -> będzie o wiele czytelniej.
Zwłaszcza, że wysyłkę maili oraz zapis do bazy będziesz najprawdopodobniej robił w wielu innych podobnych modułach w systemie.

dawid.wiklo4 napisał(a):

Z tego co zrozumiałem chodzi Ci o to, czy w interfejsie CSVReaderInterface zawrzeć funkcjonalności:

• deletePreviousUpload
• sendEmailWithErrors
• saveToDatabase

Moim zdaniem, wysyłkę email powinien realizować EmailService natomiast zapis do bazy to odpowiedzialność Repository.
Niech CSVReaderInterface realizuje funkcje z odczytem plików CSV. Inne funkcjonalności pozostaw dla innych interfejsów, klas -> będzie o wiele czytelniej.
Zwłaszcza, że wysyłkę maili oraz zapis do bazy będziesz najprawdopodobniej robił w wielu innych podobnych modułach w systemie.

EmailService będie, metoda w interfejsie będzie wykorzystywała ten serwis do wysyłki maili (jak w wieli innych miejscach).
saveToDatabase będzie wykorzystywał serwis danej encji i wykorzystywał metodę, persist.