Those are good guidelines. I'd like to add a couple of nuances. For “system” or “operations” errors (we have a database engine that executes in the address space of processes, so there can be errors such as an IO error or an inability to expand because of insufficient space in the file systems), neither the user nor the programmer can do much. In such cases, log the error to the syslog and return an error that the application can catch and do something with, like terminate gracefully. In such cases a stack trace or dump only uses up more storage space.
When writing out stack traces or core dumps (we do the latter under certain circumstances), make the content and location operationally configurable. Sometimes processes can contain sensitive (confidential) data. In development and test environments, you usually do want all or most of the data. When an application is promoted to production, you may – or may not – want that core dump to contain data from the process heap (for example). As you should not change the application when you promote to production, this type of configuration should be done externally, e.g, with environment variables, configuration files, etc. Regards – Bhaskar On Thursday, January 9, 2020 at 2:38:24 PM UTC-5, Scott Pakin wrote: > > On Tuesday, January 7, 2020 at 12:47:28 AM UTC-7, Axel Wagner wrote: >> >> Thus, panics are the right tool to use when reporting an issue that >> requires programmer attention and errors are the right tool when reporting >> an issue that requires user-attention (or, of course, can be handled >> programmatically). >> > > Nicely presented guideline! > > — Scott > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/f257f90b-c643-4bbb-9a12-acc6b72c140a%40googlegroups.com.
