В тестовом помощнике нужно завершить текущую горутину без паники. Что выведет программа и выполнится ли стр...

package main

import (
	"fmt"
	"runtime"
)

func main() {
	done := make(chan struct{})
	go func() {
		defer func() {
			fmt.Println("recover:", recover())
			close(done)
		}()
		runtime.Goexit()
		fmt.Println("after")
	}()
	<-done
}

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

Программа выведет recover: <nil>, а строка fmt.Println("after") не выполнится. runtime.Goexit завершает текущую горутину без паники, но перед завершением выполняет все зарегистрированные defer.

Исторический контекст

В Go отдельно существуют обычный возврат из функции, аварийная раскрутка через panic и принудительное завершение текущей горутины через runtime.Goexit. Такое разделение позволяет завершить горутину, сохранив гарантии defer, но не выдавая ситуацию за ошибку или панику.

recover предназначен только для перехвата активной паники. Поэтому выполнение defer само по себе не означает, что внутри него обязательно будет доступно паническое значение.

Постановка проблемы

Ошибочно считать, что любой выход из горутины через defer можно обнаружить с помощью recover. Если код трактует recover() == nil как безусловное доказательство штатного завершения, он не отличит обычный deferred-вызов от завершения через runtime.Goexit.

Кроме того, после вызова Goexit текущая функция не продолжает выполнение с места вызова. Выполняются только defer текущей горутины и её вызывающего стека, после чего горутина завершается.

Подробное решение

runtime.Goexit запускает отложенные функции в порядке, обратном их регистрации. При этом активной паники нет, поэтому вызов recover() возвращает nil. После завершения deferred-функций управление не возвращается к инструкции после runtime.Goexit.

Это отличается от panic: при панике recover внутри корректно расположенной deferred-функции может получить паническое значение и остановить дальнейшую раскрутку. При Goexit перехватывать нечего, а recover не превращает завершение горутины в обычный возврат.

В примере канал done закрывается из defer, поэтому основная горутина не зависает. Если бы close(done) находился после runtime.Goexit, он не выполнился бы, и ожидание могло бы заблокироваться навсегда.

Для передачи результата или причины завершения между горутинами следует использовать канал, контекст или явное состояние, а не пытаться кодировать Goexit через recover. Также не следует применять Goexit как замену возврату ошибки: он завершает всю текущую горутину и не возвращает вызывающему коду значение.

func worker(done chan<- struct{}) {
	defer close(done)
	runtime.Goexit()
	// Этот код недостижим.
}

Вызов close(done) гарантированно выполняется благодаря defer, но определить по recover() причину завершения нельзя: результат будет nil.

Ситуация из практики

Внутри тестового или инфраструктурного worker-кода разработчик использовал defer с recover, чтобы записывать причину любого аварийного завершения. Ветка с runtime.Goexit записывала сообщение «паники нет», хотя worker завершался принудительно и не возвращал результат.

Вариант с проверкой только recover() прост и подходит для обнаружения паники, но не различает все способы завершения горутины. Вариант с глобальным флагом хуже: он требует синхронизации и легко рассинхронизируется с фактическим управлением потоком.

Выбранное решение — передавать статус завершения явно через канал или структуру результата, а recover использовать только для паник. Это сохраняет смысл каждой конструкции: panic сообщает об аварийной ситуации, канал передаёт результат, а Goexit лишь завершает текущую горутину. В результате вызывающая сторона получает однозначный статус и не зависит от неоднозначного nil.

Что кандидаты часто упускают

1. Выполняются ли defer при runtime.Goexit?

Да. Все deferred-функции текущей горутины выполняются перед её завершением. Поэтому Goexit не следует рассматривать как мгновенное уничтожение стека: cleanup-код, разблокировка ресурсов и закрытие каналов через defer выполняются.

2. Можно ли с помощью recover отличить runtime.Goexit от обычного выхода?

Нет. При обычном выполнении deferred-функции без паники и при Goexit recover() возвращает nil. Если различие важно, его нужно фиксировать отдельным явным признаком или передавать результат через канал.

3. Что произойдёт, если deferred-функция сама вызовет panic во время Goexit?

Возникнет паника уже при выполнении defer. Если другая deferred-функция корректно вызовет recover, она сможет перехватить эту новую панику; иначе паника завершит программу по обычным правилам. Сам Goexit не превращается в значение, доступное через recover.