IllegalArgumentException czy NullPointerException dla parametru null? [zamknięte]

Powinieneś używać IllegalArgumentException (IAE), a nie NullPointerException (NPE) z następujących powodów:

Po pierwsze, NPE JavaDoc wyraźnie wymienia przypadki, w których NPE jest właściwe. Zauważ, że wszystkie z nich są wyrzucane przez runtime, gdy null jest niewłaściwie używane. W przeciwieństwie do IAE JavaDoc nie może być bardziej jasne: "rzucony, aby wskazać, że metoda została przekazana nielegalny lub niewłaściwy argument."Tak, to Ty!

Po drugie, gdy widzisz NPE w co zakładasz? Pewnie, że ktoś dereferował null. Kiedy widzisz IAE, zakładasz, że wywołanie metody na górze stosu przekazało nielegalną wartość. Ponownie, to drugie założenie jest prawdziwe, pierwsze jest mylące.

Po trzecie, ponieważ IAE jest wyraźnie zaprojektowane do walidacji parametrów, musisz założyć, że jest to domyślny wybór wyjątku, więc dlaczego zamiast tego wybrałeś NPE? Na pewno nie za inne zachowanie . czy naprawdę oczekujesz kodu wywołującego do złapiesz NPE oddzielnie od IAE i zrobisz w rezultacie coś innego? Czy próbujesz przekazać bardziej konkretny komunikat o błędzie? Ale możesz to zrobić w tekście wyjątku, tak jak powinieneś dla wszystkich innych nieprawidłowych parametrów.

Po czwarte, wszystkie inne nieprawidłowe dane parametrów będą IAE, więc dlaczego nie być spójne? Dlaczego nielegalne null jest tak wyjątkowe, że zasługuje na oddzielny wyjątek od wszystkich innych nielegalnych argumentów?

W końcu akceptuję argument podany przez inne odpowiedzi, że części API Javy używają w ten sposób NPE. Jednak API Javy jest niespójne ze wszystkim, od typów wyjątków po konwencje nazewnictwa, więc myślę, że po prostu ślepe kopiowanie (ulubionej części) API Javy nie jest wystarczająco dobrym argumentem, aby przebić te inne względy.

Standardem jest wyrzucenie wyjątku NullPointerException. Ogólnie nieomylna "efektywna Java" omawia to krótko w poz. 42 (pierwsze wydanie), poz. 60 (drugie wydanie) lub poz. 72 (trzecie wydanie)"Favor the use of standard exceptions":

" prawdopodobnie wszystkie błędne metody inwokacje sprowadzają się do nielegalnego argument lub nielegalne państwo, ale inne wyjątki są standardowo używane dla niektórych rodzajów sprzecznych z prawem argumentów i Stany. Jeśli rozmówca poda null w niektóre parametr, dla którego wartości null są zabronione, konwencja nakazuje że NullPointerException zostanie wyrzucony zamiast Nielegalnegumentexception."

Byłem za rzucaniem {[2] } dla parametrów null, aż do dzisiaj, kiedy zauważyłem metodę java.util.Objects.requireNonNull w Javie 7. Z tą metodą, zamiast robić:

if (param == null) {
    throw new IllegalArgumentException("param cannot be null.");
}

Możesz zrobić:

Objects.requireNonNull(param);

I rzuci NullPointerException Jeśli parametr, który podasz, to null.

Biorąc pod uwagę, że ta metoda jest w samym środku java.util, biorę jej istnienie za dość silną wskazówkę, że rzucanie NullPointerException jest "Java way of doing things".

Myślę, że jestem zdecydowany w każdym rate.

Zauważ, że argumenty dotyczące twardego debugowania są fałszywe, ponieważ możesz oczywiście dostarczyć wiadomość NullPointerException mówiącą, co było null i dlaczego nie powinno być null. Tak jak z IllegalArgumentException.

Dodatkową zaletą NullPointerException jest to, że w wysoce krytycznym kodzie wydajności można zrezygnować z jawnego sprawdzania null (i NullPointerException z przyjaznym Komunikatem o błędzie), i po prostu polegać na NullPointerException otrzymasz automatycznie, gdy wywołasz metodę na parametrze null. Pod warunkiem, że wywołanie metody szybko (tj. Fail fast), wtedy masz zasadniczo ten sam efekt, tylko nie tak przyjazny dla użytkownika dla dewelopera. W większości przypadków lepiej jest wyraźnie sprawdzić i wrzucić przydatny komunikat, aby wskazać, który parametr był null, ale miło jest mieć możliwość zmiany tego, jeśli wydajność dyktuje bez łamania opublikowanego kontraktu metody / konstruktora.

Podążam za projektowaniem bibliotek JDK, szczególnie zbiorów i współbieżności (Joshua Bloch, Doug Lea, ci faceci wiedzą jak projektować solidne API). W każdym razie wiele API w JDK Pro-aktywnie rzuca NullPointerException.

Na przykład Javadoc dla Map.containsKey stwierdza:

@ throws NullPointerException jeśli kluczem jest null i ta mapa nie zezwala na klucze null(opcjonalne).

Wzór idzie:

public void someMethod(Object mustNotBeNull) {  
    if (mustNotBeNull == null) {  
        throw new NullPointerException("mustNotBeNull must not be null");  
    }  
}

Cokolwiek zrobisz, nie pozwól, aby zła wartość została ustawiona i wyrzuć wyjątek później, gdy inny kod spróbuje go użyć. To sprawia, że debugowanie to koszmar. Zawsze należy przestrzegać zasady "Fail-fast".

Głosowałem za argumentem Jasona Cohena, ponieważ był dobrze przedstawiony. Rozczłonkuję go krok po kroku. ;-)

• NPE JavaDoc jawnie mówi, "inne nielegalne użycie obiektu null" . Gdyby ograniczało się tylko do sytuacji, w których runtime napotka null, a nie powinno, wszystkie takie przypadki mogłyby być definiowane znacznie zwięźle.

• Nic na to nie poradzisz, jeśli założysz coś złego, ale zakładając, że enkapsulacja zostanie zastosowana prawidłowo, naprawdę nie powinno cię to obchodzić lub zwracać uwagi na to, czy null została niewłaściwie odebrana, a nie na to, czy metoda wykryła nieodpowiednie null i zwolniła wyjątek.

• Wybrałbym NPE ponad IAE z wielu powodów

  [[3]}jest bardziej szczegółowy o charakterze nielegalnej operacji
• logika, która błędnie dopuszcza null, różni się znacznie od logiki, która błędnie dopuszcza nielegalne wartości. Na przykład, jeśli sprawdzam dane wprowadzone przez użytkownika, jeśli otrzymam wartość, która jest nie do przyjęcia, źródłem tego błędu jest użytkownik końcowy aplikacji. Jeśli dostanę null, to będzie błąd programisty.
• nieprawidłowe wartości mogą powodować przepełnienie stosu, brak błędów pamięci, parsowanie WYJĄTKÓW itp. Rzeczywiście, większość błędów zazwyczaj pojawia się w pewnym momencie jako Nieprawidłowa wartość w wywołaniu metody. Z tego powodu postrzegam IAE jako najbardziej ogólny ze wszystkich wyjątków w RuntimeException.

Ogólnie uważam, że NPE jest bardzo złośliwe, ponieważ tradycyjnie kojarzy się z kodem, który nie przestrzega Zasady Fail fast . To, plus brak JDK wypełniania NPE ciągiem komunikatów naprawdę stworzył silne negatywne nastroje, które nie są dobrze uzasadnione. Rzeczywiście, różnica między NPE i IAE z perspektywy runtime jest ściśle nazwa. Z tego punktu widzenia, im bardziej precyzyjnie podajesz nazwę, tym więcej jasności dajesz rozmówcy.

To pytanie w stylu "świętej wojny". Innymi słowy, obie alternatywy są dobre, ale ludzie będą mieli swoje preferencje, których będą bronić do śmierci.

Jeśli jest to metoda setter i null jest do niej przekazywana, myślę, że bardziej sensowne byłoby rzucanie IllegalArgumentException. A NullPointerException wydaje się mieć większy sens w przypadku, gdy próbujesz użyć null.

Więc, jeśli używasz go i jest null, NullPointer. Jeśli jest przekazywana i jest null, IllegalArgument.

Apache Commons Lang ma NullArgumentException, który wykonuje wiele rzeczy omawianych tutaj: rozszerza IllegalArgumentException, a jego jedyny konstruktor przyjmuje nazwę argumentu, który powinien być inny niż null.

Chociaż czuję, że rzucanie czegoś takiego jak NullArgumentException lub IllegalArgumentException dokładniej opisuje wyjątkowe okoliczności, moi koledzy i ja zdecydowaliśmy się odłożyć na radę Blocha w tym temacie.

Nie mogę się bardziej zgodzić z tym, co się mówi. Szybko, szybko. Całkiem niezły wyjątek.

Pytanie o to, który wyjątek rzucić jest głównie kwestią osobistego gustu. Moim zdaniem IllegalArgumentException wydaje się bardziej konkretny niż użycie NPE, ponieważ mówi mi, że problem był z argumentem, który przekazałem do metody, a nie z wartością, która mogła zostać wygenerowana podczas wykonywania metody.

Moje 2 Centy

Przyjęta praktyka, gdy należy użyć IllegalArgumentException (String message) aby zadeklarować parametr jako nieprawidłowy i podać jak najwięcej szczegółów... Tak więc, aby powiedzieć, że parametr został znaleziony jako null, podczas gdy wyjątek nie-null, można zrobić coś takiego:

if( variable == null )
    throw new IllegalArgumentException("The object 'variable' cannot be null");

Praktycznie nie masz powodu, aby w sposób niejawny używać "NullPointerException". NullPointerException jest wyjątkiem rzucanym przez maszynę Wirtualną Java podczas próby wykonania kodu na referencji null (Jak toString () ).

Właściwie, kwestia rzucania IllegalArgumentException lub NullPointerException jest moim skromnym zdaniem tylko "świętą wojną" dla mniejszości z incomlete rozumieniem obsługi wyjątków w Javie. Ogólnie zasady są proste i są następujące:

• naruszenia ograniczeń argumentów muszą być wskazane tak szybko, jak to możliwe (- >fast fail), aby uniknąć nielegalnych stanów, które są znacznie trudniejsze do debugowania
• w przypadku nieprawidłowego wskaźnika null z jakiegokolwiek powodu, rzut NullPointerException
• w przypadku nielegalnego indeksu tablicy / kolekcji, throw ArrayIndexOutOfBounds
• w przypadku ujemnej wielkości tablicy/zbioru, rzut NegativeArraySizeException
• w przypadku niezgodnego z prawem argumentu, który nie jest objęty powyższym opisem, a dla którego nie masz innego, bardziej konkretnego typu wyjątku, wyrzuć IllegalArgumentException jako wastebasket
• z drugiej strony, w przypadku naruszenia ograniczeń w polu, którego nie można było uniknąć przez szybkie fail z jakiegoś ważnego powodu, catch i rethrow jako IllegalStateException lub bardziej konkretny sprawdzony wyjątek. Nigdy nie pozwól przekazać oryginalnego NullPointerException, ArrayIndexOutOfBounds, itp w tym przypadku!

Istnieją co najmniej trzy bardzo dobre powody przemawiające przeciwko odwzorowaniu wszelkiego rodzaju naruszeń ograniczeń argumentu na IllegalArgumentException, przy czym trzeci prawdopodobnie jest tak poważny, że oznacza zły styl praktyki:

(1) programista nie może bezpiecznie zakładać, że wszystkie przypadki naruszenia ograniczeń argumentacyjnych skutkują nielegalnym wyrażeniem dokumentu, ponieważ znaczna większość klas standardowych używa tego wyjątku raczej jako kosza na śmieci, jeśli nie ma bardziej konkretnego rodzaju wyjątku. Próba odwzorowania wszystkich przypadków naruszenia ograniczeń argumentu na IllegalArgumentException w Twoim API prowadzi tylko do frustracji programistów przy użyciu Twoich klas, ponieważ standardowe biblioteki przeważnie przestrzegają różnych reguł, które naruszają Twoje, a większość użytkowników twojego API będzie ich używać jako cóż!

(2) mapowanie WYJĄTKÓW faktycznie skutkuje inną anomalią, spowodowaną pojedynczym dziedziczeniem: wszystkie wyjątki Javy są klasami i dlatego obsługują tylko pojedyncze dziedziczenie. Dlatego nie ma sposobu, aby utworzyć wyjątek, który tak naprawdę mówi zarówno o NullPointerException, jak i o IllegalArgumentException, ponieważ podklasy mogą dziedziczyć tylko z jednej lub drugiej. Rzucenie niedozwolonego wyrażenia w przypadku argumentu null utrudnia użytkownikom API rozróżnianie problemów za każdym razem, gdy program próbuje programowo rozwiązać problem, na przykład przez podawanie wartości domyślnych do powtarzania połączenia!

(3) mapowanie stwarza niebezpieczeństwo maskowania błędów: aby odwzorować naruszenia ograniczeń argumentu na IllegalArgumentException, musisz zakodować zewnętrzny try-catch w każdej metodzie, która ma jakiekolwiek ograniczone argumenty. Jednak samo złapanie RuntimeException w tym bloku połowu nie wchodzi w grę, ponieważ grozi to mapowanie udokumentowanych wyrażeń RuntimeExceptions rzucanych przez metody libery ' ego używane w Twoim na IllegalArgumentException, nawet jeśli nie są one spowodowane naruszeniem ograniczeń argumentów. Tak więc musisz być bardzo konkretny, ale nawet ten wysiłek nie chroni Cię przed przypadkowym mapowaniem nieudokumentowanego wyjątku uruchomieniowego innego API (tj. błędu) na Nielegalargumentexception twojego API. Nawet najbardziej staranne mapowanie grozi więc maskowaniem błędów programistycznych innych twórców bibliotek jako naruszenie ograniczeń argumentowych użytkowników twojej metody, czyli po prostu hillareous zachowanie!

Ze standardową praktyką z drugiej strony, Zasady pozostają proste, a wyjątek powoduje, że pozostają zdemaskowane i konkretne. Dla metody caller, zasady są łatwe, jak również: - jeśli napotkasz udokumentowany wyjątek runtime dowolnego rodzaju, ponieważ przekazałeś nielegalną wartość, albo powtórz wywołanie z wartością domyślną (dla tego wyjątku są konieczne), lub popraw kod - jeśli na drugim wykonując enccounter wyjątek runtime, który nie jest udokumentowany dla danego zestawu argumentów, Zgłoś błąd do twórców metody, aby upewnić się, że ich kod lub dokumentacja są naprawione.

Ogólnie rzecz biorąc, programista nie powinien Nigdy rzucać wyjątku NullPointerException. Ten wyjątek jest wyrzucany przez runtime, gdy kod próbuje dereferencji zmiennej, której wartością jest null. Dlatego, jeśli twoja metoda chce jawnie zablokować Null, w przeciwieństwie do sytuacji, w której wartość null wzbudza wyjątek NullPointerException, powinieneś rzucić Nielegalargumentexception.

Wyrzucenie wyjątku, który jest wyłączny dla null argumentów (czy NullPointerException czy niestandardowego typu) sprawia, że automatyczne testowanie null jest bardziej niezawodne. To automatyczne testowanie może być wykonane z odbiciem i zestawem wartości domyślnych, jak w Guava ' SNullPointerTester. Na przykład, NullPointerTester spróbuje wywołać następującą metodę...

Foo(String string, List<?> list) {
  checkArgument(string.length() > 0);
  // missing null check for list!
  this.string = string;
  this.list = list;
}

...z dwiema listami argumentów: "", null i null, ImmutableList.of(). Sprawdziłoby, czy każde z tych wywołań rzuca oczekiwaną NullPointerException. W tym celu, podanie listy null powoduje , a nie generowanie NullPointerException. Jednak zdarza się, że tworzy IllegalArgumentException, ponieważ NullPointerTester używa domyślnego ciągu "". Jeśli NullPointerTester spodziewa się tylko NullPointerException dla wartości null, wychwytuje błąd. Jeśli oczekuje IllegalArgumentException, tęskni za tym.

Jako subiektywne pytanie powinno być zamknięte, ale jako że nadal jest otwarte:

Jest to część polityki wewnętrznej stosowanej w moim poprzednim miejscu pracy i działało naprawdę dobrze. To wszystko jest z pamięci, więc nie pamiętam dokładnego sformułowania. Warto zauważyć, że nie wykorzystali sprawdzonych wyjątków, ale to wykracza poza zakres pytania. Niezaznaczone wyjątki, których używali, zostały podzielone na 3 główne kategorie.

NullPointerException: nie rzucaj celowo. NPEs to być rzucane tylko przez maszynę wirtualną, gdy odwołuje się do null reference. Należy dołożyć wszelkich starań, aby nigdy nie zostały one wyrzucone. @Nullable i @ NotNull powinny być używane w połączeniu z narzędziami do analizy kodu, aby znaleźć te błędy.

IllegalArgumentException: wyrzucony, gdy argument do funkcji nie jest zgodny z publiczną dokumentacją, tak że błąd można zidentyfikować i opisać w kategoriach przekazywanych argumentów. Sytuacja po wpadłaby w ten Kategoria.

IllegalStateException: wyrzucane, gdy funkcja jest wywołana, a jej argumenty są albo nieoczekiwane w momencie ich przekazania, albo niezgodne ze stanem obiektu, którego jest członkiem metoda.

Na przykład, były dwie wewnętrzne wersje IndexOutOfBoundsException używane w rzeczach, które miały długość. Podklasa IllegalStateException, używana, jeśli indeks był większy niż długość. Druga podklasa IllegalArgumentException, używana, jeśli indeks był negatywny. Stało się tak, ponieważ można dodać więcej elementów do obiektu i argument byłby poprawny, podczas gdy liczba ujemna nigdy nie jest poprawna.

Jak powiedziałem, ten system działa naprawdę dobrze, i ktoś musiał wyjaśnić, dlaczego rozróżnienie jest tam: "w zależności od rodzaju błędu jest dość proste, aby dowiedzieć się, co zrobić. Nawet jeśli nie możesz dowiedzieć się, co poszło nie tak, możesz dowiedzieć się, gdzie złapać ten błąd i utworzyć dodatkowe debugowanie informacje."

NullPointerException: obsłuż przypadek Null lub dodaj twierdzenie, aby NPE nie zostało wyrzucone. Jeśli umieścisz twierdzenie jest tylko jednym z dwóch pozostałych typów. Jeśli to możliwe, Kontynuuj debugowanie tak, jakby twierdzenie było tam w pierwszej kolejności.

IllegalArgumentException: masz coś nie tak na swojej stronie połączeń. Jeśli przekazywane wartości pochodzą z innej funkcji, dowiedz się, dlaczego otrzymujesz nieprawidłową wartość. Jeśli przejeżdżasz w jednym ze swoich argumenty propagują błąd sprawdzający stos wywołań, dopóki nie znajdziesz funkcji, która nie zwraca tego, czego oczekujesz.

IllegalStateException: nie wywołałeś swoich funkcji w prawidłowej kolejności. Jeśli używasz jednego ze swoich argumentów, sprawdź je i wyrzuć Nielegalargumentexception opisujący problem. Następnie można propagować policzki do stosu, aż znajdziesz problem.

W każdym razie, chodziło mu o to, że można tylko skopiować nielegalny dokument do stack. Nie ma sposobu, aby propagować IllegalStateExceptions lub NullPointerExceptions na stosie, ponieważ miały one coś wspólnego z Twoją funkcją.

Chciałem wyodrębnić argumenty Null z innych nielegalnych argumentów, więc wyprowadziłem wyjątek z IAE o nazwie NullArgumentException. Bez konieczności czytania komunikatu wyjątku, wiem, że argument null został przekazany do metody i czytając wiadomość, dowiaduję się, który argument był null. Nadal łapię NullArgumentException z obsługą IAE, ale w moich dziennikach jest miejsce, gdzie mogę szybko zobaczyć różnicę.

Dychotomia... Nie nakładają się na siebie? Tylko nie nakładające się na siebie części całości mogą tworzyć dychotomię. Jak ja to widzę:

throw new IllegalArgumentException(new NullPointerException(NULL_ARGUMENT_IN_METHOD_BAD_BOY_BAD));

Niektóre zbiory zakładają, że null jest odrzucane za pomocą NullPointerException, a nie IllegalArgumentException. Na przykład, jeśli porównasz zestaw zawierający null do zestawu, który odrzuca null, pierwszy zestaw wywoła containsAll z drugiego i złapie jego NullPointerException -- ale nie IllegalArgumentException. (Patrzę na implementację AbstractSet.equals.)

Można racjonalnie argumentować, że używanie w ten sposób niezaznaczonych wyjątków jest antypatternem, że porównywanie kolekcji zawierających null do kolekcji, które nie mogą zawierać null jest prawdopodobnym błędem to naprawdę powinno produkować wyjątek, lub że umieszczenie null w kolekcji w ogóle jest złym pomysłem. Niemniej jednak, jeśli nie jesteś skłonny powiedzieć, że {[12] } powinien rzucić wyjątek w takim przypadku, utknąłeś pamiętając, że {[1] } jest wymagany w pewnych okolicznościach, ale nie w innych. ("IAE przed NPE z wyjątkiem "c"...")

NullPointerException rzucany podczas próby uzyskania dostępu do obiektu ze zmienną odniesienia, której bieżącą wartością jest null

IllegalArgumentException wyrzucane, gdy metoda otrzymuje argument sformatowany inaczej niż oczekuje tego metoda

Według twojego scenariusza, IllegalArgumentException jest najlepszym wyborem, ponieważ {[1] } nie jest prawidłową wartością dla twojej nieruchomości.

Najlepiej, aby wyjątki runtime nie były wyrzucane. Dla scenariusza należy utworzyć zaznaczony wyjątek(wyjątek biznesowy). Ponieważ jeśli któryś z tych wyjątków zostanie wyrzucony i zalogowany, wprowadzi w błąd programistę podczas przeglądania dzienników. Zamiast tego wyjątki biznesowe nie wywołują paniki i zwykle są ignorowane podczas rozwiązywania problemów.

Definicje z linków do dwóch WYJĄTKÓW powyżej to IllegalArgumentException: rzucony w celu wskazania, że metoda została przekazana niezgodny z prawem lub niewłaściwy argument. NullPointerException: wyrzucany, gdy aplikacja próbuje użyć null W przypadku, gdy wymagany jest obiekt.

Duża różnica polega na tym, że IllegalArgumentException powinien być użyty podczas sprawdzania, czy argument do metody jest poprawny. NullPointerException ma być używany, gdy obiekt jest "używany", gdy jest null.

Mam nadzieję, że to pomoże umieścić te dwa w perspektywie.

Jeśli jest to "seter", lub gdzieś, gdzie mam członka do użycia później, mam tendencję do używania IllegalArgumentException.

Jeśli jest to coś, czego zamierzam użyć (dereference) teraz w metodzie, rzucam NullPointerException proaktywnie. Podoba mi się to lepiej niż pozwolić runtime to zrobić, ponieważ mogę dostarczyć pomocny komunikat (wydaje się, że runtime może to zrobić zbyt, ale to jest rant na inny dzień).

Jeśli nadpisuję metodę, używam dowolnej nadpisanej metody zastosowania.

Powinieneś wyrzucić Nielegalargumentexception, ponieważ będzie to oczywiste dla programisty, że zrobił coś nieprawidłowego. Programiści są tak przyzwyczajeni do oglądania NPE rzucanego przez maszynę wirtualną, że każdy programista nie zorientowałby się od razu o swoim błędzie i zacząłby rozglądać się losowo lub, co gorsza, obwiniał Twój kod za to, że jest "błędny".

W tym przypadku, IllegalArgumentException przekazuje użytkownikowi za pomocą API jasną informację, że "nie powinno być null". Jak zauważyli inni użytkownicy forum, Możesz używać NPE, jeśli chcesz tak długo, jak przekazujesz użytkownikowi odpowiednie informacje za pomocą swojego API.

GaryF i tweak porzucili" efektywne Java " (co przysięgam) odniesienia, które zalecają używanie NPE. A patrząc na to, jak inne dobre API są konstruowane jest najlepszym sposobem, aby zobaczyć, jak skonstruować swoje API.

Innym dobrym przykładem jest spojrzenie na Spring API. Na przykład org.springframework.fasola.Fasolki.instantiateClass (Konstruktor ctor, object[] args) posiada Assert.notNull (ctor, "Constructor must not be null") linia. org.springframework.util./ Align = "left" / metoda notNull (Object object, String message) sprawdza, czy przekazany argument(object) ma wartość null, a jeśli tak, rzuca Nowy Nielegalargumentexception (message), który jest następnie przechwytywany w org.springframework.fasola.Fasolki.instantiateClass(...) metoda.

Jeśli zdecydujesz się rzucić NPE i używasz argumentu w swojej metodzie, jawne sprawdzanie null może być zbędne i kosztowne. Myślę, że VM już to za Ciebie robi.