Re: [libvirt] Redesigning Libvirt: Adopting use of a safe language

On Tue, Nov 28, 2017 at 08:43:54AM +0100, Martin Kletzander wrote: > Just a quick note on what I've found out after I dedicated half day to go > through the tour of go and some other tutorials. The learning curve of Go is > even less steep than I though (for some unknown reason) it is. So that's in > favor of Go. However I haven't found out how is it possible to avoid some > SIGSEGVs or aborts since Go doesn't have many recoverable errors. And in some > cases they are not easy to spot immediately. Or making sure struct fields are > initialized. Since libvirt strives to go for recoverable errors, I see this as > a downside. Either I'm mis-understanding what you mean, or you missed the 'recover' function. In normal operation, error reporting is dealt with by having functions return a value that implements the 'error' interface. Functions can have multiple return values, so typically you would return a pair of values, the first being the data, the second being the error indicator. You check & deal with those errors with normal control flow statements. For cases where the code triggered a runtime panic() (eg dereference a Nil pointer), ordinarily that will terminate the program. At point in the callstack, however, can catch that panic using the recover() method which avoids termination, and resumes normal execution. Typically in an RPC server, the RPC dispatch method would use recover() so that if any RPC method execution panic()s the server carries on running normally, only that one method is terminated. The only thing that you can't catch is when you call into C code and that crashes. The C code can obviously arbitrarily corrupt memory, so there's no safe way to recover that. Only the Go can be recover()d from.