GoLang - try/catch에 대응하는 panic/recover
아직, 제가 Go 언어에 대해 초보자라 이게 맞는지는 모르겠지만 그래도 혹시나 이 글을 읽고 의견을 주시는 분들이 계실지 몰라 ^^ 한번 써 봅니다.
타 언어 개발자들이, 아마도 Go를 접하면서 try/catch가 없다는 점에 대해 놀랄 것입니다. 물론, Go 나름대로 장치를 마련해 두긴 했는데요, 그런데 잘못 사용하는 경우도 있어 정리를 해 둘 필요가 있어 보입니다.
가령, try/catch가 (Thread에 준하는) goroutine에서의 무한 루프에서 사용된다고 가정해 보겠습니다.
package main
import (
"bufio"
"fmt"
"os"
"time"
)
func main() {
StartLoop()
// 프로세스 종료를 막기 위해.
bufio.NewReader(os.Stdin).ReadLine()
}
func StartLoop() {
go myLoop()
}
func myLoop() {
for {
<- time.After(3 * time.Second)
now := time.Now()
fmt.Println(now)
}
}
이 상태에서, myLoop 내에 복잡한 작업이 있고 그중의 하나는 panic을 사용해 예외를 전파하는 경우도 있다고 가정해 보겠습니다.
func myLoop() {
count := 0
for {
<- time.After(3 * time.Second)
now := time.Now()
fmt.Println(now)
count ++
if count > 2 {
panic("Error occurred!")
}
}
}
하지만 panic이 발생해도 myLoop는 항상 실행하게 만들고 싶다면,
for {
// 기존의 언어에서는 try/catch를 이렇게 사용했겠지만!
// try {}
now := time.Now()
log.Println(now)
// catch { }
}
어떻게 해야 할까요? 전통적인 try/catch 관점에서 보면 아마도 defer + recover를 다음과 같이 사용하고 싶을 것입니다.
func myLoop() {
count := 0
for {
defer func() {
recover()
fmt.Printf("defer")
}()
<- time.After(3 * time.Second)
// ...[생략]...
}
}
물론, 저렇게 하면 안 됩니다. panic으로 인한 예외는 (block-scope 수준이 아닌) 함수 수준으로 스택을 풀어버리며 defer 역시 block-scope 수준에서 실행되지 않고 함수의 종료 단계에서 실행되므로 저렇게 하면 defer 함수가 누적이 됩니다. 즉, 위의 경우 count > 2 조건에 의해 defer 함수가 3번 누적되어 panic이 발생할 시점에는 마찬가지로 3번의 defer 함수가 호출되는 것을 확인할 수 있습니다.
자, 그렇다면 defer의 실행을 함수의 도입부로 빼야 하는데요,
func myLoop() {
defer func() {
recover()
fmt.Printf("defer")
}()
count := 0
// ...[생략]...
}
당연히 이 정도의 처리만으로는 for 루프를 다시 진행할 방법이 없습니다. 그리고 이를 위해 (어떤 소스 코드를 보면) 다음과 같이 자신의 함수를 호출하는 경우를 볼 수 있습니다.
func myLoop() {
defer func() {
recover()
fmt.Printf("defer")
myLoop();
}()
count := 0
// ...[생략]...
}
물론, 저렇게 해도 (언제까지라고 장담은 할 수 없지만) 동작은 합니다. 하지만, 저런 경우는 myLoop 함수의 마지막에 실행되는 defer func에서 다시 myLoop를 실행하는 식이므로 계속해서 호출 스택이 누적되는 결과를 낳습니다. 그나마 다행인 것은, Go VM의 경우 스레드의 스택도 (운영체제의 스택을 사용하지 않고) 가상화시켰기 때문에,
Go: How Does the Goroutine Stack Size Evolve?
; https://medium.com/a-journey-with-go/go-how-does-the-goroutine-stack-size-evolve-447fc02085e5
// Max stack size is 1 GB on 64-bit, 250 MB on 32-bit.
// Using decimal instead of binary GB and MB because
// they look nicer in the stack overflow failure message.
if sys.PtrSize == 8 {
maxstacksize = 1000000000
} else {
maxstacksize = 250000000
}
1GB까지 운 좋게(?) 늘어난다면 그때야 stack overflow 예외가 발생하게 될 것입니다. 어쨌든, 일종의 메모리 누수가 계속된다는 것은 좋지 않은데요, 따라서 원래 의도한 대로 하려면 다음과 같이 다시 고루틴 호출 식으로 처리해야 맞습니다.
func myLoop() {
defer func() {
recover()
fmt.Printf("defer")
go myLoop()
}()
count := 0
// ...[생략]...
}
그럼 더 이상 호출 스택도 누적되지 않고 메모리 누수 없이 자가 호출을 하게 됩니다.
C# 개발자들의 경우, secondary thread에서 예외가 발생하면 EXE 실행 프로세스가 종료하는 문제를 알고 있을 것입니다.
비동기 코드 실행 중 예외로 인한 ASP.NET 프로세스 비정상 종료 현상
; https://www.sysnet.pe.kr/2/0/11383
이와 유사한 원칙이 goroutine에 적용된다고 보시면 됩니다. 가령, 다음과 같이 고루틴을 실행하면,
package main
import (
"fmt"
"time"
)
func main() {
for {
doWork() // 동기 호출
<- time.After(5 * time.Second)
fmt.Printf("TEST")
}
}
func doWork() {
panic("test")
}
당연히, 프로그램이 비정상 종료를 합니다. 또한, 해당 호출을 "go doWork()" - 즉, 일종의 비동기 호출로 바꿔도 여전히 비정상 종료가 발생합니다. 아마도 프로그램의 안정성을 높이려면 대부분의 고루틴은 defer/recover를 적용하는 것을 고려해야 할 것입니다.
또 한 가지 고려해야 할 패턴이 finalizer에 대한 처리입니다. 가령, for 루프에서 다음과 같은 식으로 lock/unlock을 하는 경우를 보면,
package main
import (
"sync"
"time"
)
func main() {
objSync := new (sync.RWMutex)
for {
objSync.Lock()
// do work....
objSync.Unlock()
<- time.After(5 * time.Second)
}
}
자칫 중간의 코드에 따라 Lock 후에 Unlock이 되지 않을 수 있습니다. 따라서 이런 경우 defer를 이용하려고 할 텐데요,
objSync := new (sync.RWMutex)
for {
objSync.Lock()
defer objSync.Unlock()
// do work....
<- time.After(5 * time.Second)
}
당연히, defer는 함수의 종료 전에 호출하는 것이므로 위의 상황에서 또 다른 오동작을 발생시킵니다. 따라서,
이런 때는 sync 코드를 포함한 내부의 코드를 별도의 함수로 분리해야 합니다. 물론, 함수 분리가 귀찮으면 익명 함수를 정의해 처리하는 것도 방법입니다.
func main() {
for {
objSync := new (sync.RWMutex)
func () {
objSync.Lock()
defer objSync.Unlock()
// do work....
}()
<- time.After(5 * time.Second)
}
}
사소한 거 하나 더 짚어 보면, 간혹 recover 처리에 if 조건 처리로 에러가 null이 아닌 경우에만 자가 호출을 하는 경우를 보는데요,
func myLoop() {
defer func() {
fmt.Printf("defer")
if err := recover(); err != nil {
go myLoop()
}
}()
count := 0
// ...[생략]...
}
사실 저것도 경우에 따라서는 버그로 이어질 수 있습니다. 왜냐하면, panic이 언제나 interface {} 개체를 반환하지는 않는데 가령 위의 소스 코드를 그냥 panic(nil)로 호출하면,
for {
// ...[생략]...
count ++
if count > 2 {
panic()
}
}
recover의 반환으로 nil이 반환되기 때문에 myLoop가 호출되지 않을 수 있습니다. 문제는,
오류가 정말 없는 경우에도 recover는 nil을 반환하므로 그것이 panic(nil)과 구분이 안 된다는 점입니다.
암튼, 저렇게 처리해도 여전히 기존의 try/catch 동작과 완전히 같은 것은 아닙니다. 왜냐하면, for 루프만 벗어나는 것이 아니고 함수를 벗어나기 때문에 for 루프 내의 상태값(위의 경우 count)이 없어져 버립니다. 만약, 정 그런 것들이 중요하다면 loop 내의 코드를 상태값과 분리시켜 특정 함수로 몰고 defer/recover 처리하는 식으로 바꿔야 합니다.
func myLoop() {
count := 0
for {
doWork(count)
count ++
}
}
func doWork(count int) {
defer func() {
if err := recover(); err != nil {
fmt.Println(err)
}
}()
<- time.After(3 * time.Second)
now := time.Now()
fmt.Println(now)
if count % 3 == 0 {
panic("Error occurred!")
}
}
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]