> Почему вызов метода на nil-указателе в Go не приводит к падению программы, в отличие от Java? (Go)

Короткий ответ

В Go вызов метода на nil-указателе не вызывает падение, потому что методы в Go - это обычные функции с receiver-параметром. Receiver передаётся по значению (или как указатель), и если он nil, метод просто получает nil в качестве аргумента. Падение происходит только при обращении к полям или разыменовании внутри метода. В Java методы привязаны к объекту, и вызов на null всегда приводит к NullPointerException на уровне виртуальной машины.

Подробное объяснение

В Go нет классов и методов, привязанных к объекту. Метод - это синтаксический сахар над функцией, где receiver (получатель) - это просто первый параметр. Например:

GO
type Foo struct {
    X int
}

func (f *Foo) Bar() {
    fmt.Println("Bar called")
}

Здесь Bar - это функция с сигнатурой func (f *Foo) Bar(). Когда вы пишете var f *Foo = nil; f.Bar(), компилятор преобразует это в вызов (*Foo).Bar(f), где f - nil. Функция получает nil как обычный аргумент и может с ним работать, пока не попытается разыменовать.

В Java всё иначе: метод - это часть объекта, и вызов obj.method() требует, чтобы obj был не-null. JVM проверяет ссылку перед вызовом и бросает NullPointerException.

Ключевое отличие: в Go nil - это допустимое значение указателя, и язык не навязывает проверку на nil до вызова. Ответственность за обработку nil лежит на разработчике. В Java null - это "не-значение", и любое использование null в вызове метода - ошибка по определению.

На практике

На практике это означает, что в Go вы можете проектировать методы, которые безопасно работают с nil-receiver. Например, метод может проверять if f == nil и возвращать значение по умолчанию. Это часто используется для реализации паттернов вроде null object или для методов-хелперов на типах-указателях.

Однако это не значит, что нужно злоупотреблять. Если метод обращается к полям структуры, nil-receiver приведёт к panic. Поэтому в Go-коде принято явно проверять nil в начале методов, если receiver может быть nil, либо документировать, что метод не должен вызываться на nil.

В Java такой гибкости нет - вы обязаны проверять null до вызова, либо использовать Optional или другие обёртки.

Пример кода

GO
type Config struct {
    Timeout int
}

// SafeMethod безопасно работает с nil-receiver
func (c *Config) GetTimeout() int {
    if c == nil {
        return 30 // default
    }
    return c.Timeout
}

// UnsafeMethod упадёт на nil-receiver
func (c *Config) Print() {
    fmt.Println(c.Timeout) // panic: nil pointer dereference
}

func main() {
    var cfg *Config
    fmt.Println(cfg.GetTimeout()) // 30
    // cfg.Print() // panic
}

Как отвечать на собеседовании

Начните с ключевого отличия: в Go метод - это функция с receiver, а не операция над объектом. Объясните, что nil - допустимое значение, и падение происходит только при разыменовании. Приведите пример с безопасным nil-receiver. Затем сравните с Java: там метод неразрывно связан с объектом, и JVM гарантирует NPE. Подчеркните, что это осознанный дизайн Go, который даёт гибкость, но требует дисциплины. Упомяните, что panic можно перехватить через recover, но это не замена проверкам.

Что проверяет интервьюер

Интервьюер проверяет:

• понимание модели методов в Go (receiver как параметр)
• знание разницы между nil и null в разных языках
• умение объяснить, когда nil-receiver безопасен, а когда нет
• осознание trade-off между гибкостью и безопасностью
• способность сравнить подходы Go и Java на уровне архитектуры языка

Типичные ошибки

• Утверждение, что "Go не падает на nil" - это неверно, падает при разыменовании.
• Смешение nil-указателя и nil-интерфейса (interface с nil-типом и nil-значением - это разные вещи).
• Предложение использовать recover как основную защиту от nil - это антипаттерн.
• Непонимание, что в Java вызов метода на null - это гарантированный NPE, а в Go - только потенциальный panic.
• Игнорирование того, что методы с value-receiver (func (f Foo)) на nil-указателе тоже могут быть вызваны, но приведут к panic при обращении к полям.