try with resources

0

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?

3

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().

0
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.

0
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;

1

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.

0
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.

1 użytkowników online, w tym zalogowanych: 0, gości: 1