Yaz\u0131l\u0131m d\u00fcnyas\u0131nda, bazen \u00f6yle hatalarla kar\u015f\u0131la\u015f\u0131rs\u0131n\u0131z ki, ne oldu\u011funu anlamak, nerede ba\u015flad\u0131\u011f\u0131n\u0131 bulmak, hatta onu yeniden \u00fcretmek bile ba\u015fl\u0131 ba\u015f\u0131na bir m\u00fccadele haline gelir. Bu t\u00fcr hatalar genellikle sistemin derinliklerinde saklan\u0131r, kullan\u0131c\u0131lar\u0131 \u015fa\u015f\u0131rt\u0131r ve geli\u015ftiricilerin uykular\u0131n\u0131 ka\u00e7\u0131r\u0131r. \u0130\u015fte tam da b\u00f6yle bir senaryo, ge\u00e7ti\u011fimiz g\u00fcnlerde kar\u015f\u0131la\u015ft\u0131\u011f\u0131m\u0131z ve herkesi kafa kar\u0131\u015f\u0131kl\u0131\u011f\u0131na s\u00fcr\u00fckleyen bir Dijital \u00e7a\u011f\u0131n h\u0131zla de\u011fi\u015fen y\u00fcz\u00fcnde, k\u00fc\u00e7\u00fck, ba\u011f\u0131ms\u0131z ve odaklanm\u0131\u015f yaz\u0131l\u0131m ajanlar\u0131 (agents) giderek daha fazla \u00f6nem kazan\u0131yor. Bu karma\u015f\u0131k hata av\u0131n\u0131 ve \u00e7\u00f6z\u00fcm s\u00fcrecini daha iyi anlayabilmek i\u00e7in, \u00f6ncelikle ana kahramanlar\u0131m\u0131z olan Smolagents: Hafif Ajanlar\u0131n G\u00fcc\u00fc ve Riskleri<\/strong><\/p>\n Ancak, bu mod\u00fcler yap\u0131 beraberinde baz\u0131 zorluklar\u0131 da getirir. Ajanlar aras\u0131 etkile\u015fimler, durum y\u00f6netimi (state management) veya asenkron operasyonlardaki ince hatalar, tespit edilmesi zor, tutars\u0131z davran\u0131\u015flara yol a\u00e7abilir. \u00d6zellikle bir ajan\u0131n i\u00e7indeki durum de\u011fi\u015fkenleri (state variables) do\u011fru y\u00f6netilmedi\u011finde veya bir operasyon beklenmedik bir \u015fekilde ba\u015far\u0131s\u0131z oldu\u011funda, sistem genelinde kafa kar\u0131\u015f\u0131kl\u0131\u011f\u0131 yaratacak “sessiz hatalar” ortaya \u00e7\u0131kabilir.<\/p>\n Sentry: Hata \u0130zlemenin G\u00f6z\u00fc Kula\u011f\u0131<\/strong><\/p>\n Sentry, ger\u00e7ek zamanl\u0131 hata izleme ve performans izleme (performance monitoring) platformudur. Yaz\u0131l\u0131m uygulamalar\u0131n\u0131zda meydana gelen hatalar\u0131, istisnalar\u0131 (exceptions) ve performans sorunlar\u0131n\u0131 an\u0131nda tespit eder, kaydeder ve size bildirir. Sentry’nin g\u00fcc\u00fc, sadece hatalar\u0131 yakalamakla kalmay\u0131p, ayn\u0131 zamanda o hatan\u0131n olu\u015ftu\u011fu ba\u011flam\u0131 (context) \u2013 yani kullan\u0131c\u0131 bilgileri, cihaz bilgileri, y\u0131\u011f\u0131n izleri (stack traces), HTTP istek detaylar\u0131, konsol \u00e7\u0131kt\u0131lar\u0131 ve hatta uygulaman\u0131n \u00f6nceki durumlar\u0131n\u0131 (breadcrumbs) \u2013 detayl\u0131 bir \u015fekilde sunmas\u0131nda yatar. Bu detaylar, bir hatan\u0131n nedenini anlamak ve h\u0131zl\u0131ca \u00e7\u00f6zmek i\u00e7in paha bi\u00e7ilmezdir. Sentry’nin sa\u011flad\u0131\u011f\u0131 baz\u0131 temel \u00f6zellikler:<\/p>\n Bizim durumumuzda, Projemizde kullan\u0131lan Kar\u015f\u0131la\u015ft\u0131\u011f\u0131m\u0131z temel belirtiler \u015funlard\u0131:<\/p>\n Ekip olarak, bu belirtilerle kar\u015f\u0131la\u015ft\u0131\u011f\u0131m\u0131zda ilk ba\u015fta farkl\u0131 senaryolar\u0131 de\u011ferlendirdik. Veritaban\u0131 ba\u011flant\u0131 sorunlar\u0131 m\u0131 var? A\u011f gecikmeleri mi (network latencies) ya\u015fan\u0131yor? Bellek s\u0131z\u0131nt\u0131lar\u0131 (memory leaks) m\u0131 s\u00f6z konusu? Yoksa \u00fc\u00e7\u00fcnc\u00fc parti bir API’da m\u0131 problem var? T\u00fcm bu olas\u0131l\u0131klar\u0131 tek tek inceledik, log kay\u0131tlar\u0131n\u0131 (log files) tarad\u0131k, ancak herhangi bir belirgin ipucu bulamad\u0131k. Standart hata loglar\u0131, sadece genel operasyonel mesajlar\u0131 g\u00f6steriyor, sorunun k\u00f6kenine dair derinlemesine bir bilgi sunmuyordu. Bu durum, hatay\u0131 daha da “hayalet” (ghostly) hale getiriyor ve ekibin moralini bozuyordu. Herkes, bu karma\u015f\u0131k ve ele avuca s\u0131\u011fmaz hatan\u0131n pe\u015finde ko\u015farken, Sentry’nin sessizce toplad\u0131\u011f\u0131 veriler, asl\u0131nda bize do\u011fru yolu g\u00f6sterecek anahtarlar\u0131 bar\u0131nd\u0131r\u0131yordu. Ancak o anahtarlar\u0131 do\u011fru \u015fekilde yorumlamak, biraz daha zaman ve farkl\u0131 bir bak\u0131\u015f a\u00e7\u0131s\u0131 gerektirecekti.<\/p>\n Hatan\u0131n belirtileri o kadar belirsiz ve tekrarlanamazd\u0131 ki, klasik hata ay\u0131klama y\u00f6ntemleri (debugging methods) yetersiz kal\u0131yordu. \u0130\u015fte tam bu noktada, Sentry’nin projemizdeki varl\u0131\u011f\u0131, sessiz bir g\u00f6zlemci olarak paha bi\u00e7ilmez bir rol oynad\u0131. Ba\u015flang\u0131\u00e7ta, Sentry paneline bakt\u0131\u011f\u0131m\u0131zda do\u011frudan “Bu \u0130lk a\u015famada, Sentry’deki genel hata istatistiklerine odakland\u0131k. Uygulamada g\u00f6r\u00fcnen genel hatalar\u0131n say\u0131s\u0131nda belirgin bir art\u0131\u015f yoktu. Bu da bizi daha da \u015fa\u015f\u0131rt\u0131yordu, \u00e7\u00fcnk\u00fc bir sorun oldu\u011fu kesindi ama Sentry bile do\u011frudan bir “hata” olarak raporlam\u0131yordu. Ancak, Sentry’nin derinlemesine analiz yeteneklerini kullanmaya ba\u015flad\u0131\u011f\u0131m\u0131zda, resim netle\u015fmeye ba\u015flad\u0131. \u00d6zellikle \u015fu \u00f6zellikler bize yol g\u00f6sterdi:<\/p>\n Sentry, bu detayl\u0131 ve ba\u011flamsal verileri toplayarak, bize hatan\u0131n sadece “var oldu\u011funu” s\u00f6ylemekle kalmad\u0131, ayn\u0131 zamanda “nas\u0131l” ve “nerede” oldu\u011funu anlamam\u0131z i\u00e7in gerekli t\u00fcm ipu\u00e7lar\u0131n\u0131 sundu. Bu, adeta karanl\u0131k bir odada el feneriyle yolumuzu bulmak gibiydi. Sentry’nin toplad\u0131\u011f\u0131 breadcrumbs ve ba\u011flam bilgileri, bizi sorunun kayna\u011f\u0131na ad\u0131m ad\u0131m yakla\u015ft\u0131rd\u0131 ve nihayetinde, ajan\u0131n i\u00e7 durum y\u00f6netimindeki kritik bir eksikli\u011fi ortaya \u00e7\u0131karmam\u0131za yard\u0131mc\u0131 oldu.<\/p>\n Sentry’nin sa\u011flad\u0131\u011f\u0131 ipu\u00e7lar\u0131 sayesinde, hatan\u0131n genel bir sistem \u00e7\u00f6kmesi yerine, Hata ay\u0131klama s\u00fcrecini \u015fu ad\u0131mlarla y\u00fcr\u00fctt\u00fck:<\/p>\n Sentry verileri \u0131\u015f\u0131\u011f\u0131nda, ajan\u0131n bir harici API \u00e7a\u011fr\u0131s\u0131 s\u0131ras\u0131nda zaman a\u015f\u0131m\u0131 veya ge\u00e7ici bir a\u011f hatas\u0131 ya\u015fad\u0131\u011f\u0131nda, ajan\u0131n dahili Sentry’den elde etti\u011fimiz bilgilerle, sorunu yerel geli\u015ftirme ortam\u0131m\u0131zda yeniden \u00fcretmeye \u00e7al\u0131\u015ft\u0131k. \u00d6zellikle, harici API \u00e7a\u011fr\u0131s\u0131n\u0131 sim\u00fcle eden (mocking) ve zaman a\u015f\u0131m\u0131na u\u011framas\u0131na neden olan bir senaryo olu\u015fturduk. Bu senaryo, ajan\u0131n beklenen \u015fekilde tak\u0131l\u0131 kalmas\u0131na neden oldu, b\u00f6ylece hatay\u0131 canl\u0131 olarak g\u00f6zlemleyebildik.<\/p>\n<\/li>\n Sorunlu ajan\u0131n kodunu detayl\u0131 bir \u015fekilde inceledik. \u00d6zellikle asenkron i\u015flemlerin yap\u0131ld\u0131\u011f\u0131 ve ajan\u0131n durumunun g\u00fcncellendi\u011fi k\u0131s\u0131mlara odakland\u0131k. A\u015fa\u011f\u0131daki gibi bir yap\u0131 fark ettik:<\/p>\n G\u00f6rd\u00fc\u011f\u00fcm\u00fcz gibi, Bu ad\u0131m ad\u0131m te\u015fhis s\u00fcreci, Sentry’nin sa\u011flad\u0131\u011f\u0131 detayl\u0131 ba\u011flam bilgisi olmasayd\u0131 \u00e7ok daha uzun ve zorlu olabilirdi. Sentry, bize sadece bir hatan\u0131n varl\u0131\u011f\u0131n\u0131 de\u011fil, ayn\u0131 zamanda o hatan\u0131n nedenini ve nerede meydana geldi\u011fini g\u00f6steren yol haritas\u0131n\u0131 sunmu\u015ftu.<\/p>\nsmolagents<\/code> hatas\u0131yla ya\u015fand\u0131. Neyse ki, Sentry gibi g\u00fc\u00e7l\u00fc bir hata izleme (error monitoring) arac\u0131m\u0131z vard\u0131 ve o, bu karma\u015f\u0131k bilmecenin \u00e7\u00f6z\u00fcm\u00fcnde sessiz bir g\u00f6zlemci olarak bize yol g\u00f6sterdi.<\/p>\nGiri\u015f: Smolagents D\u00fcnyas\u0131nda Beklenmedik Bir Karma\u015fa Nas\u0131l Ba\u015flad\u0131?<\/h3>\n
smolagents<\/code>, ad\u0131ndan da anla\u015f\u0131laca\u011f\u0131 \u00fczere, bu t\u00fcr hafif (lightweight) ve tek g\u00f6rev odakl\u0131 ajanlar\u0131 h\u0131zl\u0131ca olu\u015fturmak i\u00e7in tasarlanm\u0131\u015f bir k\u00fct\u00fcphane. Amac\u0131m\u0131z, karma\u015f\u0131k i\u015f ak\u0131\u015flar\u0131n\u0131 daha y\u00f6netilebilir par\u00e7alara b\u00f6lmek ve her bir par\u00e7an\u0131n kendi sorumlulu\u011funu yerine getirmesini sa\u011flamakt\u0131. Bu mimari, genellikle \u00f6l\u00e7eklenebilirlik (scalability) ve bak\u0131m\u0131 kolayla\u015ft\u0131rma (maintainability) gibi avantajlar sunar. Ancak, her ne kadar k\u00fc\u00e7\u00fck ve basit olsalar da, bu ajanlar aras\u0131ndaki etkile\u015fimler veya i\u00e7 mant\u0131klar\u0131ndaki g\u00f6zden ka\u00e7an detaylar, b\u00fcy\u00fck sorunlara yol a\u00e7abilir. Projemizde de smolagents<\/code> kullanarak \u00e7e\u015fitli arka plan g\u00f6revlerini (background tasks) otomatikle\u015ftirdik. \u00d6rne\u011fin, belirli veri setlerini i\u015flemek, harici API’larla ileti\u015fim kurmak veya kullan\u0131c\u0131 bildirimlerini y\u00f6netmek gibi i\u015flevler bu ajanlar arac\u0131l\u0131\u011f\u0131yla y\u00fcr\u00fct\u00fcl\u00fcyordu. Her \u015fey yolunda giderken, kullan\u0131c\u0131lar\u0131m\u0131zdan gelen garip geri bildirimler ve sistemde g\u00f6zlemlenen tutars\u0131z davran\u0131\u015flar, bir \u015feylerin ters gitti\u011finin ilk i\u015faretleriydi. Baz\u0131 g\u00f6revler tamamlanm\u0131\u015f gibi g\u00f6r\u00fcnse de, beklenen sonu\u00e7lar elde edilemiyor, baz\u0131lar\u0131 ise hi\u00e7bir zaman ba\u015flamam\u0131\u015f gibi duruyordu. En k\u00f6t\u00fcs\u00fc, bu durum her zaman ya\u015fanm\u0131yor, rastgele aral\u0131klarla ortaya \u00e7\u0131k\u0131yordu. \u0130\u015fte bu belirsizlik, herkesi \u015fa\u015fk\u0131na \u00e7eviren ve saatlerce s\u00fcren bir hata av\u0131n\u0131n ba\u015flang\u0131c\u0131 oldu. Sentry, bu s\u00fcre\u00e7te bize sadece hatalar\u0131 g\u00f6stermekle kalmad\u0131, ayn\u0131 zamanda onlar\u0131n nedenlerini ve ba\u011flam\u0131n\u0131 (context) anlamam\u0131z i\u00e7in kritik veriler sa\u011flad\u0131.<\/p>\nTemel Kavramlar: Smolagents ve Sentry Neden \u00d6nemli?<\/h3>\n
smolagents<\/code> ve Sentry’yi yak\u0131ndan tan\u0131mak gerekiyor. Bu iki teknoloji, modern yaz\u0131l\u0131m geli\u015ftirmede kar\u015f\u0131la\u015f\u0131lan zorluklara farkl\u0131 a\u00e7\u0131lardan \u00e7\u00f6z\u00fcmler sunar ve bir araya geldiklerinde, beklenmedik sorunlar\u0131 bile ayd\u0131nlatabilirler.<\/p>\nsmolagents<\/code>, ad\u0131ndan da anla\u015f\u0131laca\u011f\u0131 gibi, “k\u00fc\u00e7\u00fck ajanlar” anlam\u0131na gelir. Bu k\u00fct\u00fcphane, genellikle tek bir sorumlulu\u011fu olan, hafif ve ba\u011f\u0131ms\u0131z i\u015f birimlerini (agent) tan\u0131mlamak ve y\u00f6netmek i\u00e7in kullan\u0131l\u0131r. Bu ajanlar, genellikle asenkron (asynchronous) \u00e7al\u0131\u015f\u0131r ve belirli olaylara tepki verir veya periyodik g\u00f6revleri yerine getirir. \u00d6rne\u011fin, bir kullan\u0131c\u0131n\u0131n yeni bir e-posta ald\u0131\u011f\u0131nda bildirim g\u00f6ndermek, bir veritaban\u0131 kayd\u0131n\u0131 g\u00fcncellemek veya bir resmin boyutunu de\u011fi\u015ftirmek gibi g\u00f6revler i\u00e7in idealdirler. Smolagents yakla\u015f\u0131m\u0131n\u0131n temel avantajlar\u0131 \u015funlard\u0131r:<\/p>\n\n
\n
smolagents<\/code> gibi arka plan s\u00fcre\u00e7lerinde \u00e7al\u0131\u015fan ve genellikle kullan\u0131c\u0131 aray\u00fcz\u00fc (UI) ile do\u011frudan etkile\u015fimi olmayan bir sistemde, Sentry’nin \u00f6nemi daha da art\u0131yor. \u00c7\u00fcnk\u00fc bu t\u00fcr sistemlerde hatalar, kullan\u0131c\u0131lar\u0131n do\u011frudan bir hata mesaj\u0131 almas\u0131 yerine, beklenen bir sonucun gelmemesi veya sistemin tutars\u0131z davranmas\u0131 \u015feklinde kendini g\u00f6sterir. Sentry, bu “g\u00f6r\u00fcnmez” hatalar\u0131 yakalayarak bize somut kan\u0131tlar sunan yegane ara\u00e7 olmu\u015ftur. Dolay\u0131s\u0131yla, smolagents<\/code>‘\u0131n mod\u00fcler yap\u0131s\u0131 ve Sentry’nin derinlemesine hata izleme yetenekleri birle\u015fti\u011finde, en karma\u015f\u0131k ve kafa kar\u0131\u015ft\u0131r\u0131c\u0131 hatalar\u0131n bile \u00fcstesinden gelmek m\u00fcmk\u00fcn hale gelir.<\/p>\nProblem: Herkesi \u015ea\u015f\u0131rtan Smolagents Hatas\u0131: Belirtiler Nelerdi?<\/h3>\n
smolagents<\/code> sistemi, belirli bir veri setini i\u015fleyip analiz eden ve sonu\u00e7lar\u0131 bir veritaban\u0131na kaydeden bir dizi ajandan olu\u015fuyordu. Bu ajanlar, \u00f6zellikle yo\u011fun veri ak\u0131\u015f\u0131n\u0131n oldu\u011fu zamanlarda, belirli aral\u0131klarla \u00e7al\u0131\u015facak \u015fekilde yap\u0131land\u0131r\u0131lm\u0131\u015ft\u0131. Ba\u015flang\u0131\u00e7ta her \u015fey yolunda giderken, zamanla kullan\u0131c\u0131lar\u0131m\u0131zdan gelen geri bildirimler ve sistemde g\u00f6zlemlenen anormallikler, bir \u015feylerin yolunda gitmedi\u011fini g\u00f6steriyordu. Belirtiler ilk ba\u015fta o kadar belirsiz ve rastgeleydi ki, sorunun k\u00f6kenini tespit etmek neredeyse imkans\u0131z gibi g\u00f6r\u00fcn\u00fcyordu.<\/p>\n\n
Sentry’nin Rol\u00fc: Sessiz G\u00f6zlemci Nas\u0131l Yard\u0131mc\u0131 Oldu?<\/h3>\n
smolagents<\/code> hatas\u0131d\u0131r!” diye ba\u011f\u0131ran bir olay g\u00f6rm\u00fcyorduk. Ancak, Sentry’nin sadece kritik hatalar\u0131 de\u011fil, ayn\u0131 zamanda uyar\u0131lar\u0131 (warnings), bilgi mesajlar\u0131n\u0131 (info messages) ve \u00f6zellikle “breadcrumbs” ad\u0131 verilen olay ak\u0131\u015flar\u0131n\u0131 da kaydetme yetene\u011fi, bize bamba\u015fka bir perspektif sundu.<\/p>\n\n
smolagents<\/code>‘lar\u0131m\u0131zda, her ajan\u0131n bir g\u00f6reve ba\u015flamas\u0131, bir API \u00e7a\u011fr\u0131s\u0131 yapmas\u0131, bir veritaban\u0131 i\u015flemi ger\u00e7ekle\u015ftirmesi ve g\u00f6revi tamamlamas\u0131 gibi kritik ad\u0131mlar\u0131 Sentry’ye breadcrumb olarak g\u00f6nderiyorduk. Bu izler, hatan\u0131n do\u011frudan bir \u00e7\u00f6kme olmasa bile, ajan\u0131n hangi a\u015famada tak\u0131ld\u0131\u011f\u0131n\u0131 veya beklenmedik bir durumla kar\u015f\u0131la\u015ft\u0131\u011f\u0131n\u0131 anlamam\u0131z\u0131 sa\u011flad\u0131. \u00d6rne\u011fin, bir ajan\u0131n “API \u00e7a\u011fr\u0131s\u0131 ba\u015flad\u0131” breadcrumb’\u0131ndan sonra “API \u00e7a\u011fr\u0131s\u0131 tamamland\u0131” breadcrumb’\u0131n\u0131n gelmedi\u011fini fark ettik. Bu, ajan\u0131n o a\u015famada bir sorun ya\u015fad\u0131\u011f\u0131n\u0131 g\u00f6steriyordu.<\/li>\nHata Ay\u0131klama S\u00fcreci: Smolagents Hatas\u0131n\u0131 Ad\u0131m Ad\u0131m Nas\u0131l Te\u015fhis Ettik?<\/h3>\n
smolagents<\/code>‘\u0131n i\u00e7 mant\u0131\u011f\u0131ndaki bir durum y\u00f6netimi (state management) probleminden kaynakland\u0131\u011f\u0131n\u0131 d\u00fc\u015f\u00fcnmeye ba\u015flad\u0131k. \u00d6zellikle breadcrumbs ve performans izleme verileri, baz\u0131 ajanlar\u0131n belirli bir asenkron i\u015flemi ba\u015flatt\u0131ktan sonra, bu i\u015flemin sonucunu beklerken “tak\u0131l\u0131 kald\u0131\u011f\u0131n\u0131” g\u00f6steriyordu. Bu, ajan\u0131n dahili durumunun (internal state) do\u011fru \u015fekilde g\u00fcncellenmedi\u011fi veya bir hatadan sonra beklenmedik bir durumda kald\u0131\u011f\u0131 anlam\u0131na gelebilirdi.<\/p>\n\n
\n
is_processing<\/code> (i\u015fleniyor) durumunu do\u011fru \u015fekilde s\u0131f\u0131rlamad\u0131\u011f\u0131na dair bir hipotez geli\u015ftirdik. Bu durumda, ajan yeni g\u00f6revleri kabul etmiyor veya mevcut g\u00f6revi tamamlad\u0131\u011f\u0131n\u0131 d\u00fc\u015f\u00fcnerek yanl\u0131\u015f bir duruma ge\u00e7iyordu.<\/p>\n<\/li>\n\nclass DataProcessorAgent:\n def __init__(self):\n self.is_processing = False\n self.current_task_id = None\n\n async def process_data(self, task_id, data):\n if self.is_processing:\n print(f\"Agent {self.current_task_id} already busy.\")\n return\n\n self.is_processing = True\n self.current_task_id = task_id\n try:\n # Harici API \u00e7a\u011fr\u0131s\u0131 veya yo\u011fun i\u015flem\n await self._call_external_api(data)\n # \u0130\u015flem ba\u015far\u0131l\u0131 olursa durum s\u0131f\u0131rlan\u0131r\n self.is_processing = False\n self.current_task_id = None\n print(f\"Task {task_id} completed successfully.\")\n except Exception as e:\n # Hata durumunda sadece loglama yap\u0131l\u0131yor, durum s\u0131f\u0131rlanm\u0131yor!\n print(f\"Error processing task {task_id}: {e}\")\n # Sentry'ye hata g\u00f6nderimi (ancak durum s\u0131f\u0131rlanmad\u0131\u011f\u0131 i\u00e7in ajan tak\u0131l\u0131 kal\u0131yor)\n # Sentry.capture_exception(e)\n <\/code><\/pre>\n<\/p><\/div>\nprocess_data<\/code> metodunda bir hata (Exception<\/code>) meydana geldi\u011finde, is_processing<\/code> bayra\u011f\u0131 False<\/code> olarak ayarlanm\u0131yordu. Bu da ajan\u0131n sonsuza kadar “i\u015fleniyor” durumunda kalmas\u0131na ve yeni g\u00f6revleri reddetmesine neden oluyordu. Hata, temel bir try-except blo\u011funun (hata yakalama blo\u011fu)<\/a> eksik veya yanl\u0131\u015f uygulanmas\u0131ndan kaynaklan\u0131yordu; yani, hata durumunda bile kaynaklar\u0131n serbest b\u0131rak\u0131lmas\u0131 veya durumun s\u0131f\u0131rlanmas\u0131 gereken finally<\/code> blo\u011funun kullan\u0131lmamas\u0131yd\u0131.<\/p>\n<\/li>\n<\/ol>\n\u00c7\u00f6z\u00fcm: Kod Seviyesinde D\u00fczeltme ve G\u00fcvence<\/h3>\n