Java'da doğru yol çözümü: 2 dizeden 2 sayıyı ayrıştırın ve ardından toplamlarını geri getirin

Oldukça aptalca bir soru. Kod verildiğinde:

public static int sum(String a, String b) /* throws? WHAT? */ {
  int x = Integer.parseInt(a); // throws NumberFormatException
  int y = Integer.parseInt(b); // throws NumberFormatException
  return x + y;
}

Java'nın iyi olup olmadığını söyleyebilir misin? Bahsettiğim şey, NumberFormatExceptionkontrol edilmeyen bir istisnadır. Sen yok bir parçası olarak belirtmek için sum()imza. Dahası, anladığım kadarıyla, kontrol edilmeyen istisnalar fikri sadece programın uygulamasının yanlış olduğunu işaret etmektir ve daha da önemlisi, kontrol edilmeyen istisnaları yakalamak kötü bir fikirdir, çünkü bu , çalışma zamanında kötü programı düzeltmek gibidir .

Biri lütfen açıklığa kavuşturur mu:

1. NumberFormatExceptionMetodun imzasının bir parçası olarak belirtmeliyim .
2. Kendi kontrol edilen istisnamı ( BadDataException) tanımlamalı NumberFormatException, yöntemin içinde işlem yapmalı ve olarak yeniden atmalıyım BadDataException.
3. Kendi kontrol edilen istisnamı ( BadDataException) tanımlamalı , her iki dizeyi de normal ifadeler gibi doğrulamalı ve BadDataExceptioneşleşmiyorsa atmalıyım.
4. Senin fikrin?

Güncelleme :

Bir nedenden dolayı kullanmanız gereken açık kaynaklı bir çerçeve olmadığını hayal edin. Yöntemin imzasına bakarsınız ve "Tamam, asla atmaz" diye düşünürsünüz. Sonra bir gün bir istisna olur. Bu normal mi?

Güncelleme 2 :

Benim sum(String, String)kötü bir tasarım olduğunu söyleyen yorumlar var . Kesinlikle katılıyorum, ancak iyi bir tasarıma sahip olsaydık orijinal sorunun asla ortaya çıkmayacağına inananlar için, işte ekstra bir soru:

Problem tanımı şu şekildedir: sayıların Strings olarak saklandığı bir veri kaynağınız var . Bu kaynak XML dosyası, web sayfası, 2 düzenleme kutusu olan masaüstü penceresi olabilir.

Amacınız bu 2 Strings'yi alan mantığı uygulamak, onları ints'ye çevirmek ve "toplam xxx" yazan mesaj kutusu göstermektir.

Bunu tasarlamak / uygulamak için kullandığınız yaklaşım ne olursa olsun , bu 2 iç işlevselliğe sahip olacaksınız :

1. Dönüştürmek için bir yer Stringiçinint
2. 2 intsaniye eklediğiniz bir yer

Orijinal gönderimin ana sorusu şudur:

Integer.parseInt()doğru dizenin geçirilmesini bekler . Ne zaman kötü bir dizge geçerseniz , bu , programınızın yanlış olduğu anlamına gelir (" kullanıcınız bir aptal" değil). Bir yandan ZORUNLU semantiğe sahip Integer.parseInt () 'e sahip olduğunuz yerde kod parçasını uygulamanız gerekir ve diğer yandan girdinin yanlış olduğu durumlarda tamam olmanız gerekir - SHOULD anlambilim .

Öyleyse, kısaca: Yalnızca ZORUNLU kütüphanelerim varsa, anlambilimini nasıl uygulayabilirim ?

Bu güzel bir soru. Keşke daha çok insan böyle şeyler düşünse.

IMHO, çöp parametrelerinden geçtiyseniz kontrol edilmeyen istisnalar atmanız kabul edilebilir.

Genel olarak konuşursak, BadDataExceptionprogram akışını kontrol etmek için İstisnaları kullanmamalısınız çünkü atmamalısınız. İstisnalar istisnai durumlar içindir. Yönteminizi arayanlar , dizelerinin sayı olup olmadığını aramadan önce bilebilirler , bu nedenle çöpün içeri girmesi önlenebilir ve bu nedenle bir programlama hatası olarak düşünülebilir , bu da kontrol edilmeyen istisnaları atmanın uygun olduğu anlamına gelir.

Bildirime gelince throws NumberFormatException- bu o kadar kullanışlı değil, çünkü NumberFormatException'ın işaretlenmemiş olması nedeniyle çok az kişi fark edecek. Bununla birlikte, IDE'ler bunu kullanabilir ve try/catchdoğru şekilde sarmayı teklif edebilir . İyi bir seçenek de javadoc kullanmaktır, örneğin:

/**
 * Adds two string numbers
 * @param a
 * @param b
 * @return
 * @throws NumberFormatException if either of a or b is not an integer
 */
public static int sum(String a, String b) throws NumberFormatException {
    int x = Integer.parseInt(a); 
    int y = Integer.parseInt(b); 
    return x + y;
}

DÜZENLENDİ : Yorumcular
geçerli puanlar verdiler . Bunun nasıl kullanılacağını ve uygulamanızın genel tasarımını düşünmeniz gerekir.

Yöntem her yerde kullanılacaksa ve tüm arayanların sorunları ele alması önemliyse, yöntemi kontrol edilen bir istisna atıyor (arayanları sorunlarla başa çıkmaya zorlamak), ancak kodu try/catchbloklarla karıştırmak olarak bildirin .

Öte yandan, bu yöntemi güvendiğimiz verilerle kullanıyorsak, bunu yukarıdaki gibi açıklayın, çünkü patlaması beklenmez ve esasen gereksiz try/catchblokların kod karmaşasından kaçınırsınız .

Kanımca istisna mantığını olabildiğince ele almak tercih edilir. Bu yüzden imzayı tercih ederim

 public static int sum(int a, int b);

Senin yöntem imzası ile ben ediyorum değil herhangi bir değişiklik. Ya sen

• Üretici algoritmanızı doğrulayabileceğiniz hatalı değerler kullanarak programlama yoluyla
• veya örneğin kullanıcı girdisinden değerler göndererek, bu durumda modül doğrulamayı gerçekleştirmelidir

Bu nedenle, bu durumda istisna işleme bir dokümantasyon sorunu haline gelir .

Numara 4. Verildiği gibi, bu yöntem tamsayılar alması gereken parametre olarak dizeleri almamalıdır. Bu durumda (java taşmak yerine sarmaladığından) bir istisna olasılığı yoktur.

 x = sum(Integer.parseInt(a), Integer.parseInt(b))

ne anlama geldiğinden çok daha net x = sum(a, b)

İstisnanın mümkün olduğunca kaynağa (girişe) yakın olmasını istiyorsunuz.

1-3 seçenekleriyle ilgili olarak, bir istisna tanımlamazsınız çünkü arayanların kodunuzun başarısız olamayacağını varsaymasını beklersiniz, METODUNUZA BENZERSİZ, bilinen hata koşulları altında ne olacağını tanımlamak için bir istisna tanımlarsınız. Yani, başka bir nesnenin etrafında sarmalayıcı olan bir yönteminiz varsa ve bir istisna atarsa ​​sonra onu iletin. Yalnızca istisna yönteminize özgüse, özel bir istisna atmalısınız (örneğinizde frex, toplamın yalnızca pozitif sonuçlar döndürmesi gerekiyorsa, o zaman bunu kontrol etmek ve bir istisna atmak, diğer yandan java ise uygun olacaktır. sarmak yerine bir taşma istisnası attıysanız, bunu iletirsiniz, imzanızda tanımlamaz, yeniden adlandırmaz veya yiyemezsiniz).

Sorunun güncellenmesine yanıt olarak güncelleme:

Öyleyse, kısaca: Yalnızca ZORUNLU kütüphanelerim varsa, anlambilimini nasıl uygulayabilirim?

Bunun çözümü, ZORUNLU kütüphaneyi sarmak ve bir ÖNERİLEN değer döndürmektir. Bu durumda, bir Tamsayı döndüren bir işlev. Bir dizge alan ve bir Tamsayı nesnesi döndüren bir işlev yazın - ya çalışır ya da boş döndürür (guava'nın Ints.tryParse gibi). Doğrulamanızı operasyonunuzdan ayrı yapınız, operasyonunuz devreye girmelidir. Geçersiz girişiniz olduğunda işleminizin varsayılan değerlerle çağrılıp çağrılmayacağı, spesifikasyonlarınıza bağlı olacaktır - bununla ilgili en çok söyleyebileceğim şey, bu kararı vereceğiniz yerin operasyonda olması gerçekten olası değildir. yöntem.

1. NumberFormatException'ı yöntemin imzasının bir parçası olarak belirtmeliyim.

Ben öyle düşünüyorum. Güzel bir belge.

2. Kendi denetlenen istisnamı (BadDataException) tanımlamalı, NumberFormatException yöntemini işlemeli ve BadDataException olarak yeniden atmalıyım.

Bazen evet. Kontrol edilen istisnaların bazı durumlarda daha iyi olduğu düşünülmektedir, ancak onlarla çalışmak oldukça PITA'dır. Bu nedenle birçok çerçeve (örn. Hazırda Bekletme) yalnızca çalışma zamanı istisnalarını kullanır.

3. Kendi denetlenen istisnamı (BadDataException) tanımlamalı, her iki dizeyi de normal ifadeler gibi doğrulamalı ve eşleşmezse BadDataException'ımı atmalıyım.

Asla. Daha fazla iş, daha az hız (istisnanın kural olmasını beklemediğiniz sürece) ve hiç kazanç yok.

4. Fikriniz?

Hiç yok.

Nr 4.

Yöntemi hiç değiştirmeyeceğimi düşünüyorum. İstisnadan iş mantığıyla incelikle kurtarabileceğim bir bağlamda olduğum yerde, çağırma yönteminin etrafına veya yığın izlemede daha yüksek bir deneme yakalama koyardım.

Aşırı olduğunu düşündüğüm için 3 numarayı yapmam.

Yazdıklarınızın başka biri tarafından (API gibi) tüketileceğini varsayarsak, o zaman 1 ile gitmelisiniz, NumberFormatException özellikle bu tür istisnaları iletmek içindir ve kullanılmalıdır.

1. Öncelikle kendinize sormanız gerekiyor, yöntemimin kullanıcısının yanlış veri girme konusunda endişelenmesi mi gerekiyor, yoksa doğru verileri girmesi mi bekleniyor (bu durumda String). Bu beklenti, sözleşmeli tasarım olarak da bilinir .

2. ve 3. Evet, muhtemelen BadDataException'ı tanımlamalısınız veya daha iyisi NumberFormatException gibi bazı istisnaları kullanmalısınız, bunun yerine standart mesajı gösterilecek şekilde bırakmalısınız. Yöntemde NumberFormatException'ı yakalayın ve orijinal yığın izlemesini dahil etmeyi unutmadan mesajınızla birlikte yeniden atın.

3. Duruma göre değişir, ancak muhtemelen NumberFormatException'ı bazı ek bilgilerle yeniden atarak giderdim. Ayrıca, bunun için beklenen değerlerin ne olduğuna dair bir javadoc açıklaması olmalıdır.String a, String b

İçinde bulunduğunuz senaryoya çok bağlı.

Durum 1. Kodda hata ayıklayan her zaman sizsiniz ve başka hiç kimse ve istisna kötü bir kullanıcı deneyimine neden olmaz

Varsayılan NumberFormatException öğesini atın

Örnek Olay2: Kod son derece sürdürülebilir ve anlaşılır olmalıdır

Kendi istisnanızı tanımlayın ve fırlatırken hata ayıklama için çok daha fazla veri ekleyin.

Kötü girişte yine de istisnaya gideceği için normal ifade kontrollerine ihtiyacınız yok.

Üretim seviyesinde bir kod olsaydı, benim fikrim birden fazla özel istisna tanımlamak olurdu, örneğin

1. Sayı biçimi istisnası
2. Taşma istisnası
3. Boş istisna vb ...

ve tüm bunları ayrı ayrı ele alın

1. Bunun yanlış girişte olabileceğini açıkça belirtmek için bunu yapabilirsiniz. Bu durumla başa çıkmayı hatırlamak için kodunuzu kullanan birine yardımcı olabilir. Daha spesifik olarak, bunu kodda kendiniz işlemediğinizi veya bunun yerine belirli bir değer döndürmediğinizi açıkça belirtiyorsunuz. Tabii ki, JavaDoc bunu da netleştirmelidir.
2. Yalnızca, arayan kişiyi kontrol edilen bir istisna ile ilgilenmeye zorlamak istiyorsanız.
3. Bu aşırılık gibi görünüyor. Bozuk girişi tespit etmek için ayrıştırmaya güvenin.

Genel olarak, bir NumberFormaException denetlenmez çünkü doğru ayrıştırılabilir girdinin sağlanması beklenir. Giriş doğrulama, halletmeniz gereken bir şeydir. Ancak, girdiyi gerçekten ayrıştırmak, bunu yapmanın en kolay yoludur. Yöntemi olduğu gibi bırakabilir ve belgelerde doğru girişin beklendiği ve işlevinizi arayan herhangi birinin kullanmadan önce her iki girişi de doğrulaması gerektiği konusunda uyarabilirsiniz.

Herhangi bir istisnai davranış, belgelerde açıklığa kavuşturulmalıdır. Ya başarısızlık durumunda bu yöntemin özel bir değer döndürdüğünü belirtmeli ( nulldönüş türünü olarak değiştirerek Integer) ya da durum 1 kullanılmalıdır. Yöntemin imzasında açıkça belirtilmesi, kullanıcının başka yollarla doğru dizeleri sağlaması durumunda onu yok saymasına izin verir, ancak yine de yöntemin bu tür bir başarısızlığı kendi başına ele almadığı açıktır.

Güncellenen sorunuza cevap verin.

Evet, "sürpriz" istisnalarının olması tamamen normaldir. Programlamaya yeni başladığında birinin aldığı tüm çalışma zamanı hatalarını düşünün.

e.g ArrayIndexOutofBound

Ayrıca her döngü için ortak bir sürpriz istisna.

ConcurrentModificationException or something like that

Çalışma zamanı istisnasının, tasarım ve kullanılabilirlik açısından algılanmasına izin verilmesi gerektiği cevabına katılsam da, onu NumberFormatException olarak atmak yerine bir IllegalArgumentException içine sarmak iyi bir fikir olacaktır. Bu daha sonra, yönteminizin sözleşmesini daha açık hale getirir ve bu sayede bir istisna attığı için kendisine yasadışı bir argüman geçirildiğini bildirir.

"Düşünün, bu bir sebepten dolayı kullanmanız gereken açık kaynaklı bir çerçeve değil. Yöntemin imzasına bakıp" Tamam, asla atmıyor "diye düşünüyorsunuz. Sonra, bir gün, bir istisna var . Bu normal mi?" yönteminizin javadoc'u her zaman yönteminizin davranışını ortaya çıkarmalıdır (ön ve son kısıtlamalar). Bir boşluğa izin verilmiyorsa javadoc'un, hiçbir zaman yöntem imzasının bir parçası olmamasına rağmen boş bir işaretçi istisnasının atılacağını söylediği söz toplama arayüzlerinin satırlarını düşünün.

İyi bir java uygulamasından bahsederken, bence her zaman daha iyidir

• Denetlenmemiş istisnayı işlemek için, ardından onu ve özel bir kontrol edilmemiş istisnayı analiz edin.

• Ayrıca, özel kontrol edilmemiş istisna atarken, istemcinizin anlayabileceği İstisna mesajını ekleyebilir ve ayrıca orijinal istisnanın yığın izini yazdırabilirsiniz.

• Özel istisnayı kontrol edilmediğinden "fırlatır" olarak bildirmeye gerek yoktur.

• Bu şekilde, kontrol edilmeyen istisnaların kullanımını ihlal etmiyorsunuz, aynı zamanda kodun müşterisi istisnanın nedenini ve çözümünü kolayca anlayacaktır.

• Ayrıca java-doc'ta düzgün şekilde belgelemek iyi bir uygulamadır ve çok yardımcı olur.

Sanırım amacınıza bağlı, ancak en azından bunu belgeleyeceğim:

/**
 * @return the sum (as an int) of the two strings
 * @throws NumberFormatException if either string can't be converted to an Integer
 */
public static int sum(String a, String b)
  int x = Integer.parseInt(a);
  int y = Integer.parseInt(b);
  return x + y;
}

Veya java.lang.Integer sınıfı için Java kaynak kodundan bir sayfa alın:

public static int parseInt(java.lang.String string) throws java.lang.NumberFormatException;

Google'ın 'Guava' kitaplığı veya Apache'nin 'Doğrulayıcı' kitaplığı ( karşılaştırma ) tarafından uygulanan giriş doğrulama modeline ne dersiniz ?

Tecrübelerime göre, bir işlevin parametrelerini işlevin başında doğrulamak ve uygun olduğunda İstisnalar atmak iyi bir uygulama olarak kabul edilir.

Ayrıca, bu sorunun büyük ölçüde dilden bağımsız olduğunu düşünürdüm. Buradaki 'iyi uygulama', geçerli olabilecek veya olmayabilecek parametreler alabilen işlevlere sahip tüm diller için geçerli olacaktır.

"Oldukça aptalca bir soru" şeklindeki ilk cümlenin çok alakalı olduğunu düşünüyorum. Neden ilk başta o imzayla bir yöntem yazasın ki? İki dizgeyi toplamak mantıklı mı? Çağıran yöntem iki dizeyi toplamak istiyorsa, geçerli ints olduklarından emin olmak ve yöntemi çağırmadan önce bunları dönüştürmek, çağıran yöntemin sorumluluğundadır.

Bu örnekte, çağırma yöntemi iki Dizeyi bir int'e dönüştüremiyorsa, birkaç şey yapabilir. Bu toplamın hangi katmanda gerçekleştiğine gerçekten bağlıdır. Dize dönüşümünün ön uç koduna çok yakın olacağını varsayıyorum (doğru şekilde yapıldıysa), bu durumda 1. büyük olasılıkla:

1. Bir hata mesajı ayarlayın ve işlemeyi durdurun veya bir hata sayfasına yönlendirin
2. Yanlış döndür (yani, toplamı başka bir nesneye koyar ve döndürmesi gerekmez)
3. Önerdiğiniz gibi bazı BadDataException oluşturun, ancak bu iki sayının toplamı çok önemli olmadığı sürece, bu aşırıdır ve yukarıda belirtildiği gibi, bu muhtemelen kötü bir tasarımdır çünkü dönüşümün yanlış yerde yapıldığını gösterir.

Bu sorunun pek çok ilginç cevabı var. Ama yine de şunu eklemek istiyorum:

Dizge ayrıştırması için her zaman "normal ifadeler" kullanmayı tercih ederim. Java.util.regex paketi bize yardımcı olmak için var. Bu yüzden asla istisna yaratmayan böyle bir şeyle sonuçlanacağım. Bir hata yakalamak istersem özel bir değer döndürmek bana kalmıştır:

import java.util.regex.Pattern;
import java.util.regex.Matcher;

public static int sum(String a, String b) {
  final String REGEX = "\\d"; // a single digit
  Pattern pattern = Pattern.compile(REGEX);
  Matcher matcher = pattern.matcher(a);
  if (matcher.find()) { x = Integer.matcher.group(); }
  Matcher matcher = pattern.matcher(b);
  if (matcher.find()) { y = Integer.matcher.group(); }
  return x + y;
}

Görüldüğü gibi, kod biraz daha uzun, ancak istediğimizi halledebiliriz (ve x ve y için varsayılan değerler belirleyebilir, else cümlelerinde ne olacağını kontrol edebilir, vb ...) Daha genel bir dönüşüm bile yazabiliriz dizeleri geçirebileceğimiz rutin, varsayılan dönüş değerleri, derlenecek REGEX kodu, atılacak hata mesajları, ...

Umarım faydalıdır.

Uyarı: Bu kodu test edemedim, bu yüzden lütfen olası söz dizimi sorunlarını özür dilerim.

Bu sorunla karşı karşıyasınız çünkü kullanıcı hatalarının uygulamanın özünde çok derinlere yayılmasına izin vermişsinizdir ve kısmen de Java veri türlerini kötüye kullanmışsınızdır.

Kullanıcı girişi doğrulama ve iş mantığı arasında daha net bir ayrım yapmalısınız, doğru veri tipini kullanın ve bu sorun kendiliğinden ortadan kalkacaktır.

Gerçek şu ki, semantiği Integer.parseInt()biliniyor - birincil amacı geçerli tam sayıları ayrıştırmak . Açık bir kullanıcı girişi doğrulama / ayrıştırma adımını kaçırıyorsunuz.