Microsoft MVP성태의 닷넷 이야기
VC++: 147. Golang - try/catch에 대응하는 panic/recover [링크 복사], [링크+제목 복사]
조회: 888
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일

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!")
    }
}




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]







[최초 등록일: ]
[최종 수정일: 9/9/2021]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




1  2  3  4  [5]  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
12966정성태2/13/2022446.NET Framework: 1155. C# - ffmpeg(FFmpeg.AutoGen): Bitmap으로부터 yuv420p + rawvideo 형식의 파일로 쓰기파일 다운로드1
12965정성태2/13/2022620.NET Framework: 1154. "Hanja Hangul Project v1.01 (파이썬)"의 C# 버전
12964정성태2/11/2022504.NET Framework: 1153. C# - ffmpeg(FFmpeg.AutoGen)를 이용한 avio_reading.c 예제 포팅파일 다운로드1
12963정성태2/11/2022511.NET Framework: 1152. C# - 화면 캡처한 이미지를 ffmpeg(FFmpeg.AutoGen)로 동영상 처리 (저해상도 현상 해결)파일 다운로드1
12962정성태2/9/2022428오류 유형: 793. 마이크로소프트 스토어 - 제품이 존재하지 않습니다. 재고가 없는 것일 수 있습니다.
12961정성태2/8/2022609.NET Framework: 1151. C# - ffmpeg(FFmpeg.AutoGen)를 이용한 비디오 프레임의 크기 및 포맷 변경 예제(scaling_video.c) [7]파일 다운로드1
12960정성태2/8/2022589개발 환경 구성: 637. ffmpeg(FFmpeg.AutoGen)를 이용한 비디오 디코딩 예제(decode_video.c) - 세 번째 이야기
12959정성태2/7/2022770.NET Framework: 1150. C# - ffmpeg(FFmpeg.AutoGen)를 이용한 비디오 디코딩 예제(decode_video.c) - 두 번째 이야기 [2]파일 다운로드1
12958정성태2/6/2022620.NET Framework: 1149. C# - ffmpeg(FFmpeg.AutoGen) - 비디오 프레임 디코딩 [2]파일 다운로드1
12957정성태2/6/2022562개발 환경 구성: 636. ffmpeg.exe를 이용해 planar 포맷의 데이터를 packed 형식으로 변환하는 방법? [2]
12956정성태2/4/2022526.NET Framework: 1148. C# - ffmpeg(FFmpeg.AutoGen) - decoding 과정 [2]파일 다운로드1
12955정성태2/4/2022528개발 환경 구성: 635. 비주얼 스튜디오에서 실행하던 ASP.NET Core (.NET Framework) 응용 프로그램을 명령행에서 실행하는 방법 (2)
12954정성태2/4/2022353VS.NET IDE: 173. 비주얼 스튜디오 - Output 창에 색상이 지정된 출력 결과가 "[39m[22m" 식의 문자로 나오는 문제
12953정성태2/2/2022542Linux: 48. Windows 11 + WSL 우분투 GUI 환경에서 한글 출력
12952정성태2/2/2022406.NET Framework: 1148. C# - ffmpeg(FFmpeg.AutoGen)를 이용한 오디오 필터 예제(filter_audio.c)파일 다운로드1
12951정성태2/2/2022415.NET Framework: 1147. C# - ffmpeg(FFmpeg.AutoGen)를 이용한 오디오 필터링 예제(filtering_audio.c)파일 다운로드1
12950정성태2/1/2022464.NET Framework: 1146. .NET 6에 추가되지 않은 Generic Math (예: INumber<T>)
12949정성태2/1/2022398.NET Framework: 1145. C# - ffmpeg(FFmpeg.AutoGen) - Codec 정보 열람 및 사용 준비파일 다운로드1
12948정성태1/30/2022498.NET Framework: 1144. C# - ffmpeg(FFmpeg.AutoGen) AVFormatContext를 이용해 ffprobe처럼 정보 출력파일 다운로드1
12947정성태1/30/2022375개발 환경 구성: 634. ffmpeg.exe - 기존 동영상 컨테이너에 다중 스트림을 추가하는 방법
12946정성태1/28/2022427오류 유형: 792. .NET Core - 로컬 개발 중에 docker 호스팅으로 바꾸는 경우 SQL 서버 접근 방법
12945정성태1/28/2022469오류 유형: 791. SQL 서버 로그인 시 localhost는 되고, 127.0.0.1로는 안 되는 문제
12944정성태1/28/2022698.NET Framework: 1143. C# - Entity Framework Core 6 개요
12943정성태1/27/2022445.NET Framework: 1142. .NET 5+로 포팅 시 플랫폼 호환성 경고 메시지(SYSLIB0006, SYSLIB0011, CA1416)파일 다운로드1
12942정성태1/27/2022502.NET Framework: 1141. XmlSerializer와 Dictionary 타입파일 다운로드1
12941정성태1/26/2022357오류 유형: 790. AKS/k8s - pod 상태가 Pending으로 지속되는 경우
1  2  3  4  [5]  6  7  8  9  10  11  12  13  14  15  ...