nilable types

[sambeau]

I keep seeing new 'proposals' to add generics and nullable types etc
here.
So I would like to throw my shabby hat into the ring with a plead-for-
simplicity approach..

It would be lovely if Go could take a more "Haskelly" aproach..
How about something like:

type foo int | nil;
var foo;

and

type num int | float;

If we could add a little Pattern atching to this all sort of lovely
things would be possible.

I'm happy without exceptions in Go.. but if you do decide to add them,
please take a look at D's 'scope' approach. It's interesting.
http://www.digitalmars.com/d/2.0/exception-safe.html

And, while I'm at it. How about a little sugar to give us properties
on basic types without having to convert them to structs, just like
attaching a method e.g.

type foo int;
prop (foo) ok bool;

or

type foos []int;
prop (foos) size int;

Yes, I realise you could just do this with a struct - but this way
you have to refer to:

foo = foo + 1;

rather than,:

foo.data = foo.data + 1

etc.

Cheers,
sam

[Mike Zraly]

On Mon, Dec 7, 2009 at 8:49 AM, inspector_jouve <kaush...@gmail.com> wrote:

[...] instead of
   try
   {
       foo();  // do processing
   }
   catch (Exception ex) {
      ...
   }
   finally
   {
       unlock(m);      // unlock the mutex
   }

Write it this way:
defer(unlock(m));
if x,err:=catch foo(); err!=nil  { // catch is an operator
  do something about it
}

This all was discussed on another thread.
http://groups.google.com/group/golang-nuts/browse_thread/thread/517754becc19e27a/44c21d045c4ccb8e?lnk=gst&q=catch#44c21d045c4ccb8e

The one problem with this approach right now is that if foo() calls Goexit() to terminate the active goroutine then the defer action will not be executed.  This is a known bug: http://code.google.com/p/go/issues/detail?id=349
 

[NoiseEHC]

> The last thing I'd like to see in go is try-catch-finally.
> Look at typical java program - all bloat! You see nothing but try-
> catch-finally, sometimes with Russian dolls of other try-catch-
> finally.
> There's a simple solution - instead of

> try
> {
> foo(); // do processing
> }
> catch (Exception ex) {
> ...
> }
> finally
> {
> unlock(m); // unlock the mutex
> }
>
> Write it this way:
> defer(unlock(m));
> if x,err:=catch foo(); err!=nil { // catch is an operator
> do something about it
> }
>

While I feel absolutely the same about the lameness of the standard Java
idiomatic code, you are a little but understating the ugliness of
idiomatic Go code.

You know the software I am currently working on contains 36.000 (not
empty) lines of partially functional style C# code which would mean
around 100-150.000 (not empty) lines of C++ code for a functionally
equivalent program. It has some GUI code but the majority is a multi
threaded server with a lot of hardware controlling low level code (and a
lot of low level interop code). So it is exactly the same kind of
problem space which is the target of Go unless I am mistaken about the
intentions of Go's authors again...

Now those 36.000 lines contain 505 throw, 220 assert, 649 using + 33
finally (using is equivalent with "}finally{obj.Dispose();}") and 184
catch constructs.
1. 58 of the 220 asserts are about some data or parameter != null checks
which is simply a weakness of C# that it does not allow defining notnull
pointers in method parameter lists. There are a LOT of places (almost
all) where I would specify notnull pointers if it would be enforced by
C# but since it is not enforced I just do not care. The 58 asserts are
used in places where notnullness is a not too trivially seen expectation
of the function.
2. 52 of the 182 catch constructs simply swallow the exception, most of
them simply wrap a single function call which would translate to the
ret, _ := func(...) Go idiom.
3. Only 75 of the 182 catch constructs use catch(T ex) at all and only 6
of them examine the thrown exception's data (logging is excluded from
this 6). All the others are just log the error or just pass the error to
an asynchronously executed packet (task) or to another thread.
4. If we exclude the catch constructs where it works as a finally which
only invoked on error (something like this: "}catch{ cleanup...;
throw;}") and also exclude where it passes the exception forward
somewhere (to a job, thread or wrapping in another exception) then there
are only 22 places where the errors are handled. Because in case of
packets the exceptions are converted into callbacks of error procedures
there can be another 20 places where errors are handled but that is all.

If I would rewrite this 36.000 lines in Go then I would simply trade
less than 50 error handling codes to 35.950 lines of idiomatic Go code
which just passes errors up the stack... Or I could just ignore error
checking and create another "robust" duck taped monstrosity...Very
promising options I have to tell you...

[sambeau]

On Dec 7, 1:49 pm, inspector_jouve <kaushan...@gmail.com> wrote:
> The last thing I'd like to see in go is try-catch-finally.
> Look at typical java program - all bloat! You see nothing but try-
> catch-finally, sometimes with Russian dolls of other try-catch-
> finally.
> There's a simple solution - instead of
>     try
>     {
>         foo();  // do processing
>     }
>     catch (Exception ex) {
>        ...
>     }
>     finally
>     {
>         unlock(m);      // unlock the mutex
>     }
>

You missed the word "Scope" above :)

I was referring to:-

The scope exit statement is an easier approach:

void abc()
{
Mutex m = new Mutex;

lock(m); // lock the mutex
scope(exit) unlock(m); // unlock on leaving the scope

foo(); // do processing
}

which is indeed very similar to this:

> Write it this way:
> defer(unlock(m));
> if x,err:=catch foo(); err!=nil  { // catch is an operator
>    do something about it
>
> }

If I understand them both correctly..

[sambeau]

On Dec 7, 3:17 pm, NoiseEHC <Noise...@freemail.hu> wrote:

> While I feel absolutely the same about the lameness of the standard Java
> idiomatic code, you are a little but understating the ugliness of
> idiomatic Go code.

Idiomatic Go code isn't ugly, it's just "different". I started out
thinking it was at least "strange" but I'm beginning to love it's
gnarly, opinionated, jovial face. I have no idea why it is getting so
much criticism. No one is being forced to use it after all - not even
Googlers.

I wouldn't want to add much to it to be honest, and I'd hate for it to
bloat. I just hope it can meet the performance goals that everyone
would like soon just to shut up one corner of naysayers. A clever,
minimalist, expressive approach to polymorphic typing would also be
nice. But that's about it.

More importantly I'd like to see a vibrant community, a large (in
scope) but minimalist (in depth) library collection and a good book.

But, apart from that it has pretty much everything I wanted added to
C, and pretty much everything I wanted taken away has been removed.

It fits my thunk better than any of the other languages out there..

[SnakE]

2009/12/7 sambeau <sam...@mac.com> 

You missed the word "Scope" above :)

I was referring to:-

The scope exit statement is an easier approach:

void abc()
{
   Mutex m = new Mutex;

   lock(m);    // lock the mutex
   scope(exit) unlock(m);      // unlock on leaving the scope

   foo();      // do processing
}

There is a "defer" statement in Go which is very similar to D's "scope(exit)".  Though "defer" is still different: it can only call one function per statement, and deferred functions are called only before the function is going to return.  You cannot do something like this in Go:

void abc()
{
   Mutex m = new Mutex;

   if (some condition)
   {

      lock(m);    // lock the mutex
      scope(exit) unlock(m);      // unlock on leaving the scope

      foo();      // do processing

      // m is implicitly unlocked here
   }

   bar(); // do processing outside the mutex
}

I think that D's scope is generally more useful.

[NoiseEHC]

While I feel absolutely the same about the lameness of the standard Java
idiomatic code, you are a little but understating the ugliness of
idiomatic Go code.
    

Idiomatic Go code isn't ugly, it's just "different". I started out
thinking it was at least "strange" but I'm beginning to love it's
gnarly, opinionated, jovial face. I have no idea why it is getting so
much criticism. No one is being forced to use it after all - not even
Googlers.
  

You know you are right on this one, since I expressed my thoughts very-very badly. What I was talking about was not idiomatic code since the idiomatic Go code does not check errors!!! What I wanted to talk about is the ugliness of a *theoretical* Go coding style which actually checks errors. I call it theoretical because nobody will code like that because almost all the lines would have the same amount of error passing code which is plain ugly.

You are also right that nobody will force me to use this language. Also because of the lack of exception handling it will not be up to the task so I will not use it even if somebody will force me to do. I could live without notnull pointers but exception handling is absolutely necessary if a programmer wants to create anything more robust than UNIX command line tools (this is only my opinion, I cannot back it by data like the statistic about the 36.000 lines of my code). The problem with the error checking style is not that exception handling makes handling errors easier (it does not) but that it makes checking ALL errors easier. Currently Go code can only check expected errors.

[Rick R]

void abc()
{
   Mutex m = new Mutex;

   if (some condition)

   {
      lock(m);    // lock the mutex
      scope(exit) unlock(m);      // unlock on leaving the scope

      foo();      // do processing

      // m is implicitly unlocked here
   }

   bar(); // do processing outside the mutex
}

I think that D's scope is generally more useful.

func abc ()
{
  m := new Mutex;
  iff (some condition, func () {

      lock(m);    // lock the mutex

      defer unlock(m);      // unlock on leaving the scope

      foo();      // do processing
      // m is implicitly unlocked here  

  });
}

func iff (cond bool, f func () )
{
  if (cond)
  {
    f();
  }
}


I don't see the problem ;)

[Ian Lance Taylor]

SnakE <snake...@gmail.com> writes:

> There is a "defer" statement in Go which is very similar to D's
> "scope(exit)". Though "defer" is still different: it can only call one
> function per statement, and deferred functions are called only before the
> function is going to return. You cannot do something like this in Go:
>
> void abc()
> {
> Mutex m = new Mutex;
>
> if (some condition)
> {
> lock(m); // lock the mutex
> scope(exit) unlock(m); // unlock on leaving the scope
>
> foo(); // do processing
>
> // m is implicitly unlocked here
> }
>
> bar(); // do processing outside the mutex
> }

if someCondition {
func() {
m.Lock();
defer m.Unlock();
foo();
}();
}

But, yes, it's awkward. Using a small separate function would be
cleaner and simpler.

Ian

[NoiseEHC]

inspector_jouve wrote:

If I would rewrite this 36.000 lines in Go then I would simply trade
less than 50 error handling codes to 35.950 lines of idiomatic Go code
which just passes errors up the stack
    

You certainly did not open the thread I was referring to. Non-local
return of errors was discussed there ad nauseam.
In this case, you trade 50 error-handling lines for 50 error-handling
lines, without any boilerplate of try/catch/finally


  

While it is true that I did not open the link because,
1. I have already read all the mailing list up to today
2. The proposals all had some problems. Otherwise I would not propose the same things.
The problems with that:
1. It treats os.Error specially (is division by zero is an os.Error?)
2. What about bool and pointer return types? (where false and nil values mean error)
3. Requires me to prefix all 36.000 lines with a ^ character (at least it will not require putting in another 36.000 lines of if ... { return ....; }). As my statistics shows there would be 50 places when the return value would be examined so probably the default of passing the error up would be a better solution...
4. It introduces another special character.
Other that these it is semantically equivalent to my exception proposal.

The problem with your last message is that you do not seem to understand that my real world example (the 36.000 LOC) was not about the exception handling mechanics (the link I did not open) but about the examples you have given in the message I have replied to:

There's a simple solution - instead of

��� try {
��� foo();��� // do processing
��� } catch (Exception ex) {
������ ...
��� } finally {
��� unlock(m);��� // unlock the mutex
��� }

Write it this way:
defer(unlock(m));

if x,err:=catch foo(); err!=nilďż˝ { // catch is an operator
�� do something about it
}

What the real world example should have been shown you is this:
1. There are only 50 in 36.000 places where you can write something interesting into the "do something about it".
2. It means that the catch mechanism can be ugly as hell, it will not affect the prettiness of Go code in a slightest sense.
3. Because of 2, your Go example does not matter at all in the big picture.
4. What is important is that the default must be to pass up errors (35.950 places).

+5. And you know the try{}finally{} is not too much uglier than defer. The reason Java code is so ugly because it uses exceptions for returning expected errors and not only to return unexpected errors. Also because of the lame checked exception mechanics, all the exceptions must be handled on some idiotic ways (while it would be necessary only on 50 places).

What you are right is that if I would have been opened the link then I would not write about 35.950 pass ups but about 35.950 ^ characters. Much better.

[atomly]

2009/12/7 NoiseEHC <Nois...@freemail.hu>

Currently Go code can only check expected errors.

I think this is the most important thing about not having exceptions in Go.  Sure, Java code can get really ugly with tons of try {} catch {} finally {} blocks everywhere throughout the language.  I don't really recommend that we recreate that monstrosity.  The great thing about exceptions, though, is being able to propagate error data back up the stack so that they can be handled in a few key spots where it's actually possible to do something about the problems.  As it stands with Go's syntax, you're forced to deal with every error locally or go through great lengths to pass it back up the stack (resulting in a lot more code than you'd need in Java or the like).

Take, for example, the webapp I write at my day job.  We rolled our own custom web framework and we just do a try {} catch(Exception e) {} at the dispatcher level.  Sure, we catch all expected errors throughout the code, but anything truly exceptional will unravel all the way back up the stack and get directed to our DefaultErrorHandler that knows how to make a graceful exit and display an error page to the user that is as helpful as possible (according to the exception type).  That sort of thing would result in a lot more code in Go (having to pass back a lot of return values) or else, perhaps, some sort of exception channel mechanism.

--
:: atomly ::

[ ato...@atomly.com : www.atomly.com  : http://blog.atomly.com/ ...
[ atomiq records : new york city : +1.917.442.9450 ...
[ e-mail atomly-new...@atomly.com for atomly info and updates ...

[atomly]

I will once again say that Erlang should be looked to for inspiration in this regard.  I've always like supervision trees, spawn_link and being able to monitor another thread.  Erlang is probably the best language I've ever seen for error handling/fault tolerance, especially in a highly-concurrent, message-passing environment.

I guess you could try to just idiomatically express a lot of the same things with Go, but it's hard when things aren't guaranteed by the compiler.  I find myself often creating a boolean channel called "done" or something along those lines when I start a goroutine-- perhaps I should look into expanding this concept so that rather than just blocking on receive to ensure computation finishes, I make it possible to send meaningful information back in the event of error...  Not as powerful as Erlang's monitoring, but most likely useful.

[hong]

> > Currently Go code can only check expected errors.
>
> I think this is the most important thing about not having exceptions in Go.

It will work in some cases, but not others. For example, unexpected
nil will cause process to crash. Does everyone want their process
to crash when it happen? I certainly don't in some cases.

Exception should be used to handle exceptional cases. By such
definition, they are supposed to be rare and there should not be
many places need to handle it. So the ugliness of the syntax
does not really matter.

BTW, your example was a bad choice. If catch Exception, do
something about it and quit nicely. If you consume the os.Error
in Go, you will end up exactly the same problem.

Hong

[atomly]

On Mon, Dec 7, 2009 at 9:47 PM, hong <ho...@google.com> wrote:

Exception should be used to handle exceptional cases. By such

definition, they are supposed to be rare and there should not be
many places need to handle it. So the ugliness of the syntax
does not really matter.

I think that's a really bad argument-- just because something is rare doesn't mean it's OK to make it ugly.  More importantly, one of the primary things that makes the Java exception syntax so ugly is that it's _everywhere_ in your code.

 

BTW, your example was a bad choice. If catch Exception, do
something about it and quit nicely. If you consume the os.Error
in Go, you will end up exactly the same problem.

What?  I don't know how what you're trying to say here.

If you're talking about my webapp example, then you're wrong; I definitely don't want my entire webapp to quit because there was an unexpected exception.  I'd say my example is exactly right-- the exception should find its way back up the stack to the error handling section of the code so that it can be dealt with appropriately.  Trying to do something like this in Go, every controller, service, etc would have to know how to deal with these cases.  Instead, only one spot in my code needs to know how to deal with unexpected exceptions and they're handled cleanly and consistently.

Say you have the following:

Distpatcher

|_Controller

   |_UserService

   |_CommentService

      |_DBConnector

      |_MCConnector

      |_FSConnector

If I'm rendering a webpage using a controller that, in turn, calls into multiple services that themselves call into databases, memcached, filesystem, etc., then I don't want to have to deal with unexpected errors in every place that they occur.  If there's an unexpected exception in the above tree while reading from Memcached, then I want execution to stop and I want the exception to bubble up to the Dispatcher level so that it can be dealt with accordingly.  The Service and Controller layers don't even have to know that this type of error is possible, it just passes through them in the stack until it finds code that knows how to deal with it appropriately.

[Hong Zhang]

I think we are talking across each other already. I hope I don't
confuse more, or you can correct it.

If people don't like exception only because of syntax, we can do
something like this:

result, error = catch expression;

This is almost the same as current code. The difference are:
* os.Error becomes the exception type.
* You don't need to declare os.Error as return value.
* You write "throw err" instead of "return 0, err".
* Errors are automatically propagated if not caught.
* Minimum change to Go's current look and feel.

If people don't like exception because it is exception, then it is
a different story. At Google, we have half of code in C++, which
uses error code and crash on exception, and another half in Java
where most errors are exceptions. It is 50-50 choice among many
people. I can work either way and certainly don't expect any
agreement on this.

In Go, unexpected exception kills the process (which is I don't like),
so I am not sure what you discuss unexpected errors below. As
far as I know, nil is the most common unexpected error.

Hong

[atomly]

On Mon, Dec 7, 2009 at 11:38 PM, Hong Zhang <ho...@google.com> wrote:
> I think we are talking across each other already. I hope I don't
> confuse more, or you can correct it.
>
> If people don't like exception only because of syntax, we can do
> something like this:
>
> result, error = catch expression;
>
> This is almost the same as current code. The difference are:
> * os.Error becomes the exception type.
> * You don't need to declare os.Error as return value.
> * You write "throw err" instead of "return 0, err".
> * Errors are automatically propagated if not caught.
> * Minimum change to Go's current look and feel.

I think we are actually somewhat on the same page, then. I actually
don't mind that syntax you described that much, but I'd even be happy
with leaving things how they are, if it were possible to make the foo
[, bar] := baz() syntax in your own programs, or something to that
effect.

One of my biggest problems with Go as a language is that it doesn't
give you the facilities to do things that the language itself is able
to do. If you could define "exception" return values for your
functions and they could be propagated up the stack, I'd be quite
happy with that.

Say you had something like this:

func readFromDb(c *db.Conn) b *bytes,Buffer, e Exception {
}

Then, when you called the function, you could do:

buff, e := readFromDb(conn);

and you would catch the exception, but you could also do:

buff := readFromDb(conn);

if an exception occurred, then it would just be propagated up the
stack, perhaps to a place where a catch() was called. If there's no
proper handler, then it would abort the program.

This would be very much like the comma ok syntax for maps, channels,
etc. If you check for exception, you can catch it.

In this same vein, it really bothers me that the language is able to
support generics (channels and maps can work on any type), but there's
no facility to do the same sort of thing in your own code...

> In Go, unexpected exception kills the process (which is I don't like),
> so I am not sure what you discuss unexpected errors below. As
> far as I know, nil is the most common unexpected error.

I'm talking about unexpected errors in any app. For example, the
webapp I was describing has about 30 million users and does hundreds
of millions of page views a day. Obviously, any exceptional case that
can happen, does. Take the following: when reading from a file, you
might reach EOF and that's an expected error. That file might also be
hosted on NFS, though, and having the server go down would count as an
unexpected error and not the sort of thing that you can just recover
from in your function-- that's a textbook "exceptional" case that you
would want to stop execution, propagate up the stack and handle in a
very specific manner and you'd probably only want that handler code to
exist in one place.

[Hong Zhang]

I think we are mostly on the same page. I don't have much to add.

Regard syntax "res, err := catch expr", the code is much easier to
read and gets proper attention. While "res, err := expr" can be easily
confused with regular declaration. Anyway, it is a minor point.

Hong

[Vincent Risi]

I dislike the idea that a function return has error explicitly in it.
I would prefer that the underlying runtime returns an error state with
valid function returns. I agree that the try catch blocks are
exceeding ugly in code. I think the calling function should set up a
catch for each error that can be thrown by the called function and if
it does not a compile error should be raised. I think the called
function should be able to elect certain errors to be fatal and
terminate execution and if these type errors occur then the call stack
should be followed allowing for all defers to be completed. I would
not like to see the setjump longjump for error handling.

On Dec 8, 7:27 am, Hong Zhang <h...@google.com> wrote:
> I think we are mostly on the same page. I don't have much to add.
>
> Regard syntax "res, err := catch expr", the code is much easier to
> read and gets proper attention. While "res, err := expr" can be easily
> confused with regular declaration. Anyway, it is a minor point.
>
> Hong
>
> On Mon, Dec 7, 2009 at 21:15, atomly <ato...@atomly.com> wrote:

> > [ e-mail atomly-news-subscr...@atomly.com for atomly info and updates ...

[SnakE]

2009/12/8 inspector_jouve <kaush...@gmail.com>

> * os.Error becomes the exception type.
> * You don't need to declare os.Error as return value.
> * You write "throw err" instead of "return 0, err".
> * Errors are automatically propagated if not caught.
> * Minimum change to Go's current look and feel.

You know what, I think it's reasonable. It's just a more concise
syntax for catching exceptions. There's still a problem of HOW to
define error hierarchy so that it won't become a woodoo science. Right
now, in java I have no idea whether I have to introduce my own
exception hierarchy, or try to reuse one of 1 million java exception
types, or what. All these spiritual pursuits in the area of exceptions
in java look comical to me.

Please consider also the "wraperr" statement (see my post above). I
dealt with megatons of code written for big customers who (quite
logically) insist that every exception should contain context info
that user can understand - that is, whether it's something user can
deal with (and how to deal with), or it's a bug (then they have to
report it to developers). To address this, programs very often catch
error, add context info and rethrow. This is statistically so common
case that it may warrant     introduction of language construct.
Maybe, this is overkill, I don't know, but I think programs can become
cleaner.

I totally agree that adding context to errors is much more common than actually handling errors, and would be even more common if it were easy.  I'm looking forward to a more detailed design of your wrap statement.

As to error hierarchies, Go specifically refuses to organize types into hierarchies.  This means that some other approach to error classification should be developed.

[Vincent Risi]

I think errors should not be put into classification hierarchies. What
makes an error type a subservient type? If I have hierarchies I have
to write catches in a particular order. Also no catch(...) please.

On Dec 8, 4:41 pm, SnakE <snake.sc...@gmail.com> wrote:
> 2009/12/8 inspector_jouve <kaushan...@gmail.com>

[Jonathan Amsterdam]

> 1. I have already read all the mailing list up to today

Great! Then you read Rob Pike's message explaining how to simulate
exceptions in Go, and you read my message that pointed you to a clean
implementation of that idea in a recent Go source tree (http://
www.google.com/url?sa=D&q=http://code.google.com/p/go/source/browse/src/pkg/exp/exception/exception.go%3Fspec%3Dsvnaff697587839774c069bbf35bc120257d4a83865%26r%3Daff697587839774c069bbf35bc120257d4a83865&usg=AFQjCNED5zny5ckMaZaVteMbnpeIn453fg).

So you know that Go already supports exceptions. So what's your point?
Or is it possible that you read everything, but you didn't understand
everything?

If you want to have a substantive conversation, let it be about thread-
local storage. That would fix the main problem with the exception
mechanism: that you have to pass the throw function down the call
tree.

[NoiseEHC]

Jonathan Amsterdam wrote:

1. I have already read all the mailing list up to today
    

Great! Then you read Rob Pike's message explaining how to simulate
exceptions in Go, and you read my message that pointed you to a clean
implementation of that idea in a recent Go source tree (http://
www.google.com/url?sa=D&q=http://code.google.com/p/go/source/browse/src/pkg/exp/exception/exception.go%3Fspec%3Dsvnaff697587839774c069bbf35bc120257d4a83865%26r%3Daff697587839774c069bbf35bc120257d4a83865&usg=AFQjCNED5zny5ckMaZaVteMbnpeIn453fg).

  

I have read them too (BTW I did not read the first week of messages to be precise).

So you know that Go already supports exceptions. So what's your point?
Or is it possible that you read everything, but you didn't understand
everything?

  

The pointer you just have gave me emulates a try/catch semantics. Unfortunately *in* *my* *opinion* this is not the critical thing which is missing from the language. What missing is to check every possible error (even stack overflows and out of memory in the future when the runtime will be hardened) automatically. How it throws or how it catches is a little detail in my opinion because as my 36.000 LOC example shows, there are very few places where you can do anything about unexpected errors (if we assume that we handle expected errors via return values). That is why I usually use "exceptions" in quotation marks.

If you want to have a substantive conversation, let it be about thread-
local storage. That would fix the main problem with the exception
mechanism: that you have to pass the throw function down the call
tree.
  

While having some thread local storage in a system package would be nice (goroutine local storage would be cool) it is only remotely touches what I think about "exception" handling. (Even if it would be implemented using goroutine local storage what is just an implementation detail).

So the problem is not to have a package which emulates it (your one seems to satisfy perfectly this goal) but to have to be able to catch and automatically forward both runtime and user code errors somehow. But that is just my $0.02.

[Jonathan Amsterdam]

> So the problem is not to have a package which emulates it (your one
> seems to satisfy perfectly this goal) but to have to be able to catch
> and automatically forward both runtime and user code errors somehow. But
> that is just my $0.02.

Agreed, having built-in errors crash the program is harsh. I argue
that they should only crash the current goroutine.

[Jonathan Amsterdam]

Try this: http://code.google.com/p/go/source/browse#hg/src/pkg/exp/exception

On Dec 8, 11:56 am, inspector_jouve <kaushan...@gmail.com> wrote:
> This link says "NOT FOUND".
>
> Isn't it ironic that groundbreaking article on exceptions fell victim
> of exception itself?

[ziyu_huang]

On 12月8日, 下午4時46分, Vincent Risi <vincent.r...@gmail.com> wrote:
> I dislike the idea that a function return has error explicitly in it.

You know many programs on the planet are still use this old approach
because it's most easy wildy used
approach . Especially working with lagacy codes. It's scaring only if
programmer don't like to handle it.
Try and catch has nothing different to this approach. I think most
people complains about it because they
want to use throws statement in function like java :).

I want have a error recovery machanism for server programming. But
"try-catch-final" ? there is not much different to Go's mutilple
return.