RuntimeException oluşturan yöntemler, yöntem imzasında bunu belirtmeli mi?

Örneğin, çerçevelerdeki / JDK'daki birçok yöntem,

java.lang.SecurityException 

ancak bu, yöntem imzasında belirtilmez (çünkü bu normalde kontrol edilen istisnalar için ayrılmış bir uygulamadır). Yöntem sigs'lerinde RuntimeExceptions bildirmenin birçok faydası olduğunu iddia etmek istiyorum (örneğin, statik tür kontrolüne benzer). Sarhoş muyum yoksa başka şekilde mi?

İmzada denetlenmemiş bir istisna beyan etmem, çünkü bu API'nin kullanıcısını yanıltıcıdır. İstisnanın açıkça ele alınmasının gerekip gerekmediği artık açık değildir.

Bunu javadoc'ta beyan etmek daha iyi bir yaklaşımdır, çünkü birisinin gerekli olduğunu düşündüğünde onu halletmesine izin verir, ancak isterse görmezden gelebileceğini bilir. Bu, işaretli ve işaretsiz arasındaki ayrımı netleştirir.

Gönderen Oracle Java öğretici :

"Bir yöntemin API'sini, atabileceği istisnalar da dahil olmak üzere belgelemek o kadar iyiyse, neden çalışma zamanı istisnalarını da belirtmiyorsunuz?" Çalışma zamanı istisnaları, bir programlama probleminin sonucu olan sorunları temsil eder ve bu nedenle, API istemci kodunun bunlardan kurtarması veya herhangi bir şekilde işlemesi makul bir şekilde beklenemez. Bu tür sorunlar arasında sıfıra bölme gibi aritmetik istisnalar; boş bir başvuru yoluyla bir nesneye erişmeye çalışmak gibi işaretçi istisnaları; ve çok büyük veya çok küçük bir dizin aracılığıyla bir dizi öğesine erişmeye çalışmak gibi endeksleme istisnaları.

Çalışma zamanı istisnaları bir programın herhangi bir yerinde meydana gelebilir ve tipik bir programda çok sayıda olabilir. Her yöntem bildirimine çalışma zamanı istisnaları eklemek zorunda kalmak, bir programın netliğini azaltır.

Koleksiyon # add için javadoc'a bir göz atın

Bahsedilen çok sayıda kontrol edilmemiş istisna var:

Throws:
UnsupportedOperationException - add is not supported by this collection.
ClassCastException - class of the specified element prevents it from being added to this collection.
NullPointerException - if the specified element is null and this collection does not support null elements.
IllegalArgumentException - some aspect of this element prevents it from being added to this collection.

Sabrınız varsa, yöntemleriniz tarafından atılan olası istisnaları bu şekilde ayrıntılı bir şekilde belgelemenizi tavsiye ederim. Bir bakıma, bunu kontrol edilmeyen istisnalar için yapmak daha da önemlidir, çünkü kontrol edilen istisnalar bir şekilde kendi kendini belgelendirir (derleyici çağıran kodu onları kabul etmeye zorlar).

Benim bakış açıma göre, en azından yöntem için javadoc'da çalışma zamanı istisnalarını bildirmek daha iyidir. Bunu imzada beyan etmek, bir şeyler ters gittiğinde neler olabileceğini daha da açık hale getirir. Bu bilgileri sağlamayı önermemin ana nedeni budur.

Bilginize: Zaman ilerledikçe (şimdi 2017'de) şimdi bunları yalnızca javadoc ile belgelemeye ve kontrol edilen istisnalardan mümkün olduğunca kaçınmaya daha çok eğiliyorum.

Benim görüşüme göre, kontrol edilmeyen istisnalar, doğalarına aykırı olduğu için asla yöntem imzasında beyan edilmemelidir.

Bununla birlikte, bir yöntemin Javadoc'ta @throws'daki olası koşullara dikkat ederek bazı kontrol edilmemiş istisnalar atması muhtemelse, neyin yanlış gidebileceğini anlamada yöntemi kullanan diğerlerine yardımcı olabilir. Bu, yalnızca arayanların işleyebileceği istisnalar için kullanışlıdır (örneğin, hatalı giriş nedeniyle NPE vb.)

Başkaları tarafından kullanılmak üzere bir api yazıyorsanız, amacınızın api'de açık bir şekilde belgelenmesi için yeterli neden vardır ve yöntem imzasında RuntimeExceptions bildirmenin dezavantajı yoktur.

Bu, kontrol edilen istisnalara ilişkin tartışmayla ilgilidir . Çoğu kişi, istisnaların yöntem imzalarında belirtilmemesi gerektiği konusunda hemfikirdir.

Çalışma zamanı istisnalarının nasıl kullanılması gerektiğine dair bir tartışma da var . Çalışma zamanı istisnalarının bir programlama hatasını veya ölümcül bir durumu göstermesi gerektiği konusunda bir gönderene katılıyorum. Yani onları imzada beyan etmenin pek bir değeri yok. Her yöntem potansiyel olarak birinden geçebilir.