OSNews

Well, no.. surely the concept is similar as the following (Sorry, OS news seems to flatten the indentation in the preview, so probably the post too):

class X
{
void static Main()
{
X x = new X();
try
{
x.Whatever();
}
finally
{
//clean up or whatever
x.Dispose(); //e.g.
x = null; //...or
}
catch(Exception ex)
{
//silently swallow anything we don't otherwise handle
}
}

void Whatever()
{
try
{
y();
}
finally
{
//defer
}
catch(MySuperException ex)
{
//recover
}

}

void y()
{
try
{
throw new SomeUnhandledException("We don't handle this");
}
catch(SomeOtherException ex)
{
//recover
}
catch(AnotherKindOfException ex2)
{
//recover
}
}

}






Exception handling and Error handling go hand in hand in modern OO languages.

It's possible to use panic/recover as a fairly limited traditional exception handling system, but it's not nice to use and Go programmers won't expect it. Similarly you can return null to indicate errors in Java but Java programmers won't expect that either.




They are distinct concepts and Go treats them as such.
By making them distinct you make your error handling easier to reason about and more resilient to changes in other parts of the code base. Even Java's checked exceptions have a neat trick of hiding the source of an exception from the code that has to handle it.