2 ms·
Something like this Go snippet: func parsefile(string) string { } func thatfunctionthatcrashedinC() { defer func() { if err := recover(); er
by YZF 2y ago
Something like this Go snippet:
func parsefile(string) string {
}
func thatfunctionthatcrashedinC() {
defer func() {
if err := recover(); err != nil {
log.Println("panic occurred:", err)
}
}()
result := parsefile(badfilethatcrashesC);
if result[0] == 'A' {
}
}
so... using a type that can't be nil. recovering from runtime panics (you have to do that but this can be enforced by standards and also it can happen up the stack for all code, e.g. like http handlers do by default in the Go standard library). More importantly these errors are not segfaults in Go, i.e. there's "exceptions" you can and should catch and there are exceptions you can't.
- ArtixFox 2y agoYou have all that in C++ too. Exceptions are near zero cost and used everywhere, sometimes even in embedded stuff too.
- YZF 2y agoSure. I speak C++ ;) You can do this in C++ but I think it's generally more crash prone than Go. Based on personal experience of ~20 years of C++ and ~10 of Go I've debugged many a core dump in C++ and I think zero in Go. You can restrict yourself to the somewhat safer parts of C++ for sure.