Samebug има голяма колекция от сривове от мрежата: проследяване на стека с прикачена уеб страница, където я намерихме. Групирахме тези сривове въз основа на редица критерии: тип изключение, софтуерен компонент, който хвърля изключението, основни източници, където ги намерихме и т.н. Идентифицирахме също често срещани модели на грешки (частта от проследяването на стека, която е една и съща в няколко различни проследяване на стека), което причинява много проблеми на разработчиците.

След това започнахме да анализираме данните, за да придобием известна представа за най-честите изключения на Java. Разгледахме 3 измервания: броя на събраните сривове, броя на уеб страниците, където се е появило проследяване на стека, свързано с изключението, и броя на моделите на грешки, идентифицирани от нашия алгоритъм. Тъй като в Samebug работим върху създаването на платформа, която помага за лесно отстраняване на грешки, такъв анализ беше от съществено значение. Ние разрешаваме грешки, за които е абсолютно необходимо да знаем кои се появяват най-често, за да можем да бъдем ефективни. Ето какво разбрахме от анализа:

Когато разглеждаме броя на сривовете, можем да видим, че не е изненадващо, че NullPointerException е най-често срещаната грешка. Може да се намери и на най-големия брой уеб страници сред типовете изключения, както виждаме на диаграма 2:

Разликата между това и предишното е, че една уеб страница може да съдържа няколко различни трасирания на стека (напр. множество трасирания на стека, поставени в един проблем на GitHub). Можем да видим, че има няколко разлики в реда на типовете изключения: напр. IllegalArgumentException и IllegalStateException имат по-забележимо присъствие в дискусиите в мрежата в сравнение с тяхната важност, измерена само в броя на сривовете.

В диаграма 3 класирахме типовете изключения според това колко модели на грешки са свързани с тях. Може да се види, че някои типове изключения се класират по-ниско, отколкото в първата графика. Това означава, че към тях са свързани по-малко модели, но тези модели имат средно повече сривове.

Най-забележителният такъв тип е ClassNotFoundException. Всъщност, когато работихме върху групирането на модели на грешки, вече забелязахме, че моделите, които най-често се срещат при различни сривове, с други думи, които се споделят от множество различни разработчици, са свързани с ClassNotFoundException. Писали сме за „как да обработваме ClassNotFoundExceptions“ преди, така че нека сравним разпределението на модела на срив/грешка с това на NullPointerException. Открихме, че много модели ClassNotFoundException имат огромен брой сривове в нашата база данни. Междувременно в случая на NullPointerException има много повече модели на грешки, но те събират средно значително по-малко сривове. Илюстрирахме това в диаграмата по-долу (имайте предвид, че числата са в логаритмична скала).

В случая на NullPointerException има повече от 30 000 модела, всеки с по-малко от 10 свързани срива и 65 модела със 100–999 срива. В случая на ClassNotFoundException има само 10 000 модела с по-малко от 10 свързани срива, но има много повече модели с повече от 100 срива в сравнение с NullPointerExceptions. Има дори модели с 1000+ свързани срива и един шаблон има повече от 10 000 свързани срива.

Този резултат може да бъде изненада за мнозина, така че нека разберем причината за това:

Извикванията в кода, които водят до срив с NullPointerException, са доста разпръснати, защото идват от много различни библиотеки и влизат в сила веднага, когато човек направи грешка, докато ClassNotFoundException се генерира от стандартен механизъм на JVM и следователно води до много следи на стека със същия модел на грешка.

Човек може да си помисли, че както NullPointerException, така и ClassNotFoundException са грешки, толкова основни, че всеки разработчик знае как да ги разреши лесно, но честата им поява във форумите противоречи на това предположение, така че писането на ръководство за това как да се справят с тях определено е полезно за много разработчици. В случая на NullPointerException е трудно да се напишат няколко общи решения, защото проблемът е различен във всяка библиотека. В случая на ClassNotFoundException има някои модели на грешки, общи за много разработчици. Разбира се, има специфични решения за различни среди или рамки, които използвате, но предоставеното общо решение все още има смисъл.

Направихме този анализ, за ​​да можем да изберем интелигентно с кои модели да започнем. Стигнахме до извода, че моделите за грешка ClassNotFoundException трябва да са на първо място, дори ако има повече сривове с NullPointerException.

В момента търсим експерти по Neo4J, Java Runtime, MySQL, Google Guava, JUnit, Tomcat, Hibernate, Spring, Android, които да напишат кратки резюмета и решения за модели на грешки, свързани с тези компоненти. Ако се интересувате, свържете се с [email protected].