3 ms·

So, as others said, panic is very similar to throw, it's just intentionally ugly and strongly discouraged. There are linters which will tell you when you forge

by NateDad 12y ago

So, as others said, panic is very similar to throw, it's just intentionally ugly and strongly discouraged. There are linters which will tell you when you forget to check an error code. You say that unhandled errors can cause data corruption, but what about improperly cleaning up resources? That happens all the time... you have your data partially written to disk and something throws an exception, if you don't have your cleanup code in a try/finally, then bam, corrupt data. That's a lot more likely with the mindset of generally just letting exceptions fly.

WorldWideWayne 12y ago
>> but what about improperly cleaning up resources? What about it? Are you saying that error return values somehow force programmers to properly cleanup resources? >> That happens all the time... How are you quantifying that? I write code in exception bearing languages all the time and never have this problem. Why would you begin a partial write and then call some code that would likely produce errors or exceptions? That sounds like a recipe for corrupt data no matter the style of error catching. A better way would be to use a method of writing that is basically atomic. A lot of your arguments in this thread sound a bit contrived.
- NateDad 12y ago
  I'm saying that most people who complain about Go's verbosity do not take resource cleanup into consideration. They think they can let exceptions fly without any try/catch or try/finally and everything will be fine, which is obviously untrue. Sorry, what I meant by "happens all the time" is that there are often cases where you need cleanup code that gets called if the function doesn't exit cleanly. There's very often no atomic way to perform a series of actions. Please keep in mind, I was being very vague on purpose. There is almost always a list of actions that you want to either all succeed, or else you need to do some cleanup if later ones fail. In code with exceptions, you don't always know what can throw. Unless you're using java code that has been written with strict checked exceptions, you have to assume any external function you call can throw. Even if it doesn't now, it might when Bob from the next team over decides that now it should. I really don't think it's at all contrived. I'm not saying you can't write this code with exceptions, I'm saying it's harder than it needs to be, and it's at least as verbose as Go, if you're doing all the right things with your try/catch/finally's.
dragonwriter 12y ago
> So, as others said, panic is very similar to throw, it's just intentionally ugly and strongly discouraged. I thought it was officially only discouraged across module boundaries -- e.g., library code shouldn't let panics "escape".

by NateDad 12y ago

WorldWideWayne 12y ago

>> but what about improperly cleaning up resources? What about it? Are you saying that error return values somehow force programmers to properly cleanup resources? >> That happens all the time... How are you quantifying that? I write code in exception bearing languages all the time and never have this problem. Why would you begin a partial write and then call some code that would likely produce errors or exceptions? That sounds like a recipe for corrupt data no matter the style of error catching. A better way would be to use a method of writing that is basically atomic. A lot of your arguments in this thread sound a bit contrived.

NateDad 12y ago
I'm saying that most people who complain about Go's verbosity do not take resource cleanup into consideration. They think they can let exceptions fly without any try/catch or try/finally and everything will be fine, which is obviously untrue. Sorry, what I meant by "happens all the time" is that there are often cases where you need cleanup code that gets called if the function doesn't exit cleanly. There's very often no atomic way to perform a series of actions. Please keep in mind, I was being very vague on purpose. There is almost always a list of actions that you want to either all succeed, or else you need to do some cleanup if later ones fail. In code with exceptions, you don't always know what can throw. Unless you're using java code that has been written with strict checked exceptions, you have to assume any external function you call can throw. Even if it doesn't now, it might when Bob from the next team over decides that now it should. I really don't think it's at all contrived. I'm not saying you can't write this code with exceptions, I'm saying it's harder than it needs to be, and it's at least as verbose as Go, if you're doing all the right things with your try/catch/finally's.

dragonwriter 12y ago

> So, as others said, panic is very similar to throw, it's just intentionally ugly and strongly discouraged. I thought it was officially only discouraged across module boundaries -- e.g., library code shouldn't let panics "escape".