yoklateknik mülakat
GelişimGeçmiş

Backend Java Exceptions Mülakat Soruları

75 doğrulanmış Backend Java Exceptions mülakat sorusu — cevaplarıyla çöz, açıklamalarıyla öğren, gerçek simülasyonda kendini test et.

Gerçek simülasyonu dene →

Örnek sorular

Java ExceptionsZorluk 1
Aşağıdaki dört standart sınıftan hangisi Java'da checked (denetimli) exception'dır?
  • aNullPointerException, çünkü null referansına erişmek yeterince yaygın bir hata olduğu için derleyici bunu ele almaya zorlar
  • bIOException, çünkü doğrudan Exception'dan türer, RuntimeException'dan değil, bu yüzden checked'dır✓
  • cArithmeticException, çünkü sıfıra bölme her zaman derleme anında tespit edilebilir ve bu yüzden checked'dır
  • dIllegalStateException, çünkü her zaman deklare edilmesi ya da yakalanması gereken ciddi bir programlama hatasını işaret eder
Açıklama:Checked exception, RuntimeException'dan TÜREMEYEN her Exception alt sınıfıdır. IOException doğrudan Exception'dan türediği için checked'dır ve throws ile deklare edilmeli ya da yakalanmalıdır. NullPointerException, ArithmeticException ve IllegalStateException'ın hepsi RuntimeException'dan türer, dolayısıyla unchecked'dır ve derleyici bunları ele almaya asla zorlamaz.
Java ExceptionsZorluk 2
class Res implements AutoCloseable {
    private final String name;
    Res(String name) {
        this.name = name;
        if (name.equals("B")) {
            throw new RuntimeException("cannot open " + name);
        }
        System.out.println("open " + name);
    }
    public void close() { System.out.println("close " + name); }
}

public class Main {
    public static void main(String[] args) {
        try (Res a = new Res("A"); Res b = new Res("B")) {
            System.out.println("body");
        } catch (RuntimeException e) {
            System.out.println("caught: " + e.getMessage());
        }
    }
}

Ne yazdırılır?
  • aopen A, caught: cannot open B — A kaynağı asla kapanmaz çünkü constructor'ı çalışmış ama try gövdesi hiç başlamamıştır
  • bopen A, close A, caught: cannot open B — JVM, A kaynağının zaten başarıyla oluşturulduğunu takip eder ve B'nin constructor'ı başarısız olup try gövdesi hiç çalışmasa bile A'yı kapatır✓
  • cHiçbir şey yazdırılmaz ve JVM anormal sonlanır, çünkü try-with-resources başlığındaki başarısız bir constructor kaynak listesini tanımsız bir durumda bırakır
  • dopen A, open B, close A, caught: cannot open B — B'nin constructor'ı herhangi bir kaynak doğrulanmadan önce tamamlanana kadar çalışır ve sonrasında yalnızca ilk kaynak kapatılır
Açıklama:try-with-resources, başarısızlıktan önce başarıyla oluşturulmuş olan kaynakları ters sırayla kapatır — bunun için try gövdesinin başlamış olması gerekmez. Burada a tamamen oluşturulur ("open A" yazdırılır), sonra b'yi oluştururken atama yapılmadan önce exception fırlatılır, yani b hiçbir zaman kapatılacak bir kaynak olmamıştır. İfade geri sarılırken yine de a'yı kapatır ("close A"), ardından RuntimeException catch bloğuna yayılır.
Java ExceptionsZorluk 2
public class Main {
    static int test() {
        try {
            return 1;
        } finally {
            return 2;
        }
    }
    public static void main(String[] args) {
        System.out.println(test());
    }
}

Ne yazdırılır?
  • a2, çünkü finally içindeki return ifadesi try'dan bekleyen dönüş değerini iptal eder ve metodun asıl sonucu olur✓
  • b1, çünkü try bloğunun dönüş değeri finally çalışmadan önce zaten kesinleşmiştir ve değiştirilemez
  • cKod derlenmez, çünkü finally bloğu içinde return ifadesine izin verilmez
  • d0, çünkü hem try hem finally'den return yapmak dönüşü tamamen iptal eder ve metot deklare edilen dönüş tipinin örtük varsayılan değerine düşer
Açıklama:finally içindeki bir return, try/catch'ten bekleyen her dönüşü (ya da fırlatılan istisnayı) yutar ve metodun gerçek sonucu haline gelir. Burada try 1 dönmeyi planlar ama bu değer geri verilmeden önce finally çalışır ve yerine 2 döner — yani test() 2 döner. Bu bilinen bir finally tuzağıdır ve geçerli Java'dır, derleme hatası değildir.
Java ExceptionsZorluk 3
public class Main {
    static void inner() {
        try {
            throw new RuntimeException("boom");
        } finally {
            System.out.println("inner-finally");
        }
    }
    public static void main(String[] args) {
        try {
            inner();
        } catch (RuntimeException e) {
            System.out.println("caught: " + e.getMessage());
        }
    }
}

Ne yazdırılır?
  • acaught: boom — finally bloğu hiç çalışmaz çünkü exception başka bir metotta fırlatılıp yakalanır
  • binner-finally — finally bloğu çalıştıktan sonra yürütme durur, bu yüzden exception main'e hiç ulaşmaz
  • cinner-finally, caught: boom — exception yayılırken önce finally çalışır, sonra çağıran onu yakalar✓
  • dcaught: boom, inner-finally — önce exception yakalanır, sonra finally bir temizlik adımı olarak çalışır
Açıklama:try içinde bir exception fırlatıldığında, finally — kendisi hiçbir şey yakalamasa da — exception çağrı yığınında yukarı yayılmaya devam etmeden ÖNCE çalışır. Bu yüzden inner()'dan çıkılırken önce inner-finally yazdırılır, ancak ondan sonra exception main'in catch bloğuna ulaşır ve caught: boom yazdırılır.
Java ExceptionsZorluk 2
try {
    Files.readAllBytes(Path.of("data.txt"));
    Integer.parseInt("x");
} catch (IOException | NumberFormatException e) {
    e = new NumberFormatException("replaced");
    System.out.println(e.getMessage());
}

Bu multi-catch bloğu hakkında ne doğrudur?
  • aDerlenir ve doğru çalışır, çünkü multi-catch parametresi normal bir yerel değişken gibi yeniden atanabilir
  • bDerlenmez, çünkü multi-catch parametresi e örtük olarak final'dır ve catch bloğu içinde yeniden atanamaz✓
  • cDerlenmez, çünkü IOException ve NumberFormatException, exception hiyerarşisindeki konumlarından bağımsız olarak aynı multi-catch ifadesinde birlikte bulunamaz
  • dDerlenir, ama e'yi yeniden atamanın sessizce hiçbir etkisi olmaz ve orijinal yakalanan exception'ın mesajı yazdırılır
Açıklama:Bir multi-catch parametresi (catch (A | B e)) örtük olarak final'dır, bu yüzden e = new NumberFormatException(...) bir derleme hatasıdır. Bu kısıtlama tek tipli bir catch parametresi için geçerli değildir, o yeniden atanabilir. IOException ve NumberFormatException gibi birbiriyle ilişkisiz istisna tiplerini aynı multi-catch ifadesinde birleştirmek, biri diğerinin alt tipi olmadığı sürece tamamen geçerlidir.
Java ExceptionsZorluk 1
Bir metot, throws IOException deklare eden başka bir metodu çağırıyor ve çağıran metot bunu yakalamıyor. Kodun derlenmesi için çağıran metot ne yapmalıdır?
  • aÖzel bir şey gerekmez, çünkü IOException unchecked'dır ve derleyici ele alınıp alınmadığını hiç kontrol etmez
  • bÇağrıyı boş bir catch bloğu olan bir try içine sarmalıdır, çünkü Java her checked çağrı noktası için bunu zorunlu kılar
  • cIOException'ı özel olarak yakalamalıdır; çağıran metodun kendi imzasında throws ile deklare etmek derleyici tarafından hiçbir zaman geçerli bir alternatif olarak kabul edilmez
  • dYa IOException'ı yakalamalı ya da kendi imzasında throws IOException deklare ederek yükümlülüğü kendi çağıranına devretmelidir✓
Açıklama:IOException checked bir exception'dır, bu yüzden derleyici "yakala ya da belirt" kuralını uygular: onun kaçmasına izin verebilecek her metot ya try/catch ile ele almalı ya da kendi imzasında throws IOException deklare etmelidir — bu da aynı yükümlülüğü bir sonraki çağırana devretmekten başka bir şey değildir.

Uzmanlığa göre

C#/.NET 450Go 450Java 450Node.js 450PHP 450Python 450

Kıdeme göre

Backend JuniorBackend MidBackend Senior

Diğer alanlar

FrontendFullstackDevOps / CloudAI EngineerVeritabanıMobilGüvenlikQA / Test OtomasyonuData EngineerOyun GeliştirmeML Engineer

3300 soruluk Backend bankasında kendini sına.

Mülakata başla