4 ms·
I'd be surprised if you're in a minority -- maybe here that's true but most Go developers I know and work with are pretty content with the state of affairs rega
by xyzzy_plugh 3y ago
I'd be surprised if you're in a minority -- maybe here that's true but most Go developers I know and work with are pretty content with the state of affairs regarding error handling.
- morelisp 3y agoMost Java developers I know and work with are pretty content with the state of affairs regarding error handling. But it sucks too.
- threeseed 3y agoJava is significantly better than Go. You have the option to explicitly handle every error, not handle errors for certain methods, or bubble up errors to a single error handler or any combination thereof.
- bb88 3y agoWell RuntimeErrors (NullPointerExceptions's and the like) weren't never explicitly required to be on the method signature. I was trying to remember who it was, but one author I thought had recommended subclassing every exception as a Runtime exception for this reason.
- threeseed 3y agoYes there are checked and unchecked exceptions. NullPointerException don't really make sense as checked because almost every method will have some exposure to null values. But the idea is that encapsulating methods can check for those and translate them into other exception types or just let it be handled by a global exception handler. Java is not the best for error handling by any stretch. But it's easily better than Go.
- free652 3y ago>Java is not the best for error handling by any stretch. But it's easily better than Go. Nah. If you ever worked in a big enough company you would have: try & catch Throwable at the main entry. Go forces to think about every error. C# doesn't even have checked errors, after using Java for 10 years - checked exceptions are dumb. Go doesn't have a stack trace in the error and thats dumb.
- majormajor 3y ago> Go forces to think about every error. Unless you just always return it up the chain without thinking about it like the bulk of the code I've encountered. No more thoughtful than "catch and reraise" or "just throw." And like in Java, an NPE ain't getting caught by the error return of a function in Go either.
- masklinn 3y agoEven if you ignore this, assume nobody ever created an editor macro to smash, go has several glaring holes which make it very possible (and reasonably easy) to miss errors entirely. And unlike Java, those errors are just gone, they won’t be breaking noisily eventually.
- threeseed 3y agoNot sure what you mean there. With checked exceptions you need to either handle them directly or yes you can wrap them in a RuntimeException and catch it in main. I've done a decade of old-school JVM development at enterprise companies. Never seen any codebase where no exceptions are locally handed.
- pjmlp 3y agoUntil your beloved C# application crashes in production on black friday, because you forgot to catch an exception.
- morelisp 3y agoQED.
- gaganyaan 3y agoThat's the blub paradox in action
- Smaug123 3y agoSame with the Go developers I know, which means it falls to me to raise the bugs against their stuff ;)
- starttoaster 3y agoGo developer here. I'm pretty content with the state of error handling.
- metaltyphoon 3y agoDo some Go on the side, I’m not content and Go yearly survey shows many are not content either as it’s the #1 complaint.
- bb88 3y agoI do too. Error handling is fine-ish mostly. The issue I have is there are three forms of error handling. Errors : Fine. Panics : Weird because golang already had errors. Segfaults: Gah! (though this is a cgo issue apparently) See https://news.ycombinator.com/item?id=37908655 https://news.ycombinator.com/item?id=37908655 and https://rachelbythebay.com/w/2023/10/16/env/ https://rachelbythebay.com/w/2023/10/16/env/
- randomdata 3y ago> Panics : Weird because golang already had errors. It is true that panic allows any value to propagate, so technically you can use it to carry errors, along with anything else you can imagine (names, email addresses, audio, whatever). But the intent is for it to be used for communicating exceptions. You will notice panic's behaviour mirrors exception handling systems found in some other popular languages. But errors, along with names and email addresses for that matter, are decidedly not exceptional.
- Cthulhu_ 3y agoPanics are discouraged to use though, or, only when you intend to have the whole app crash immediately, which is rarely the case. It's there, but you shouldn't use them in practice.
- metaltyphoon 3y agoPanics recovery should almost always be used on web services. You do want them to crash a web server.
- jjnoakes 3y agoI wear two hats when I develop in go. One is for robust long-lived systems and for those I don't mind verbose error handling. The other is small quick scripts and for those I really wish I had a non-verbose option.
- Cthulhu_ 3y agoA few years ago there was an effort to come up with improving error handling, but after several months of back and forth, various concepts, etc etc, the consensus was that the existing error handling wasn't too bad, and/or the proposed alternatives weren't significantly better.