Linked by fran on Fri 22nd Jul 2011 21:02 UTC
Google "Now everyone can use Google's Go language on the company's App Engine cloud platform as the company has announced that the Go runtime, which has been in development since it was announced at Google I/O, is now generally available."
Thread beginning with comment 482231
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: As a programmer...
by jessta on Tue 26th Jul 2011 09:48 UTC in reply to "RE[4]: As a programmer..."
jessta
Member since:
2005-08-17


An exception is still an error that occurred in your code. This can be from a multitude of reasons, but many languages now treat exceptions as first class errors.


Exceptions aren't recoverable. Your can't plan for them and handle them. An exception is a bug in your program and it can't continue until someone fixes the bug. It can restart but that's not really error handling.

Errors are expected so code can be written to handle them and attempt some kind of recovery. Treating exceptions as errors leads to attempts to recover from unrecoverable situations.

but in a true OO language the Exception carries a wealth of extra information that the programmer can use to diagnose the error condition.


I assume you haven't actually had a look at how Go does error handling. Functions can return multiple values so it's idiomatic to return a value and an error value.
The error value can be null or contain a data structure containing information about the cause of the error.

Reply Parent Score: 2

RE[6]: As a programmer...
by Kalessin on Tue 26th Jul 2011 20:33 in reply to "RE[5]: As a programmer..."
Kalessin Member since:
2007-01-18

Exceptions aren't recoverable. Your can't plan for them and handle them. An exception is a bug in your program and it can't continue until someone fixes the bug. It can restart but that's not really error handling.

Errors are expected so code can be written to handle them and attempt some kind of recovery. Treating exceptions as errors leads to attempts to recover from unrecoverable situations.


I find that particular distinction interesting since it's completely backwards from what I'd expect. I would expect errors to be unrecoverable and exceptions to be at least potentially recoverable. For instance, I would expect running out of memory or dereferencing a null pointer to be an error, whereas I would expect trying to read from a closed socket to be an exception.

It's all a matter of semantics, because it's ultimately the concepts that matter rather than exactly what you call them. But still, if the official Go terminology has error referring to something recoverable and exception referring to something unrecoverable, it strikes me as being incredibly backwards.

I guess that it just goes to show that you have to make sure that everyone is on the same page terminology-wise before discussing something, or you're going to have communication problems.

Reply Parent Score: 1

RE[7]: As a programmer...
by JonathanBThompson on Wed 27th Jul 2011 02:16 in reply to "RE[6]: As a programmer..."
JonathanBThompson Member since:
2006-05-26

Running out of memory in a system that has more than one process in use is an exception: it's something you can reasonably expect to happen, due to the nature of the system. So, too, would a closing socket, as stuff happens beyond your control. However, your statement about dereferencing a null pointer? That's clearly an error, since that is 100% preventable: either you allocate memory/objects/resources and get a pointer to them, or you get a null, and you never try to dereference a pointer that's not been set to start with: thus, that's a very definite error.

However, that doesn't change the fact that in both Java and C# that an exception is thrown by the runtime, which allows it to possibly be recovered from (to some extent) if you attempt to dereference a null pointer/reference. In C/C++, your program will likely be aborted by the OS, unless you're using some implementation of structured exception handling (Windows has this in something similar to C++ semantics) or appropriate signal handling in Unix/Linux and similar OSes.

Reply Parent Score: 2