>don’t think ‘single shot, short lived processes’ are the typical Go >paradigm - they are usually larger , multi layer, long lived “server” >processes. It’s my opinion that Gos error handling is a problem for >these types. I am not saying it can’t be done but it’s harder to >design/deliver/maintain. >
I can't agree. Long lived go server processes are made of many single shot worker tasks that can send errors back just the same. >Exceptions (used properly) provide a lot of information when reading >the code. I don’t get the same feedback with Gos error returns. AFAICT, this is just structuring. There is nothing stopping your server processes from having a documented error processor, handling returned error types, possibly even from distributed services. The only real difference is if the errors are tunnelled in plain sight or behind the scenes. You could store rather than returning errors if you wanted to. I don't think Go users should be encouraged to hide errors away. -- 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/65F3B450-5507-4E3C-A09B-905DCF4C0006%40gmail.com.
