| |||||||||||||
Quotes of the weekQuotes of the weekPosted Jun 28, 2012 21:18 UTC (Thu) by kjp (subscriber, #39639)Parent article: Quotes of the week
>>most Go programmers come from languages like Python and Ruby<<
I'm sure that works great with the GO error handling model... hope they're not forgetting to check every close() for an error status.
(Log in to post comments)
Quotes of the week Posted Jul 3, 2012 22:31 UTC (Tue) by twm (guest, #67436) [Link]
As a Python programmer, I find Go's lack of exceptions to be one of its many attractive features. You only have to be bitten by an uncaught exception in production so many times to start questioning the whole concept.
Quotes of the week Posted Jul 4, 2012 0:27 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
Try writing any non-trivial code in Go and you'll be bitten by ignored error code values.
That's even worse, exceptions are at least visible.
Quotes of the week Posted Jul 4, 2012 4:11 UTC (Wed) by twm (guest, #67436) [Link]
So don't ignore error code return values. You wrote buggy code that doesn't handle errors; it's not like Ruby or Python prevents the same. At the very least, it's a problem you can take measure of via static analysis---try doing that in Python. Worse, many Python library authors don't think that the exceptions a routine can throw are worth documenting! Go's style should at least make writing reliable software possible without try... except Exception blocks around everything. I'll readily admit that my experience with Go is limited to small programs, and I am partially extrapolating from C experience.
Quotes of the week Posted Jul 4, 2012 6:02 UTC (Wed) by raven667 (subscriber, #5198) [Link]
If you are going to check return codes how is that different, other than stylistically from putting try/except blocks around things? You have to do error checking and handling for either case, in the case of exceptions you have a default action (abort) and a detailed message, in the case of return codes your app weaves drunkenly along with incorrect/corrupt data doing bad things.
Quotes of the week Posted Jul 4, 2012 9:28 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
Nope.
You DON'T need try..except blocks in correctly designed code. Well, you need them, but mostly on the upper level. The main reason for their use it to free acquired resources in case of exceptional conditions and that can be done well by "with(res):" statements (try-with-resources in Java).
C++ has an even better mechanism - destructors. It has a tremendous advantage over other error handling mechanisms because it unites error handling paths and normal exit paths.
Exception traces Posted Jul 4, 2012 13:09 UTC (Wed) by man_ls (subscriber, #15091) [Link] With exceptions users have a nice stack trace that they can send to the developer. At the uppermost level I just catch the errors to print them nicely along with debug information. When people send me stack traces I can find the error almost instantly.In the Google Play App Store (or however it is called this week) they have taken this idea to the next level: when the user clicks on "inform the developer" Google aggregates the information and shows the traces to the developer. Try doing that with ignored error values...
Exception traces Posted Jul 6, 2012 4:15 UTC (Fri) by twm (guest, #67436) [Link] The concept of a stack trace is not part of the exception error handling model. You can get stack traces in Go too; runtime.Callers looks like a good place to start.
Exception traces Posted Jul 6, 2012 8:05 UTC (Fri) by man_ls (subscriber, #15091) [Link] Well, then I suppose you need both exceptions and stack traces. The idea being that the stack trace is generated automatically by the runtime environment at the point that throws the exception and handled in the catch clause. Without exceptions stack traces have to be generated manually, which is not useful for unexpected error conditions.
Exception traces Posted Jul 11, 2012 6:51 UTC (Wed) by jamesh (guest, #1159) [Link]
Does that help you at the top level if you've called some well behaved Go code that checks and passes up error conditions, and you want to know precisely where the error originated?
Wouldn't an exception + stack trace be easier to debug?
Quotes of the week Posted Jul 4, 2012 20:14 UTC (Wed) by robert_s (subscriber, #42402) [Link]
"So don't ignore error code return values. You wrote buggy code that doesn't handle errors"
So don't not-handle exceptions. Or use an execution environment that can easily recover from such problems. You wrote buggy code that doesn't handle exceptions. Or would you prefer the inner exception-raising function just failed silently? Or segfault?
|
|||||||||||||