I'm not following this in great depth, but popping in quickly:
> I would prefer to consolidate the error returns
> into optional arguments and a single return type. For
> example, instead of
> (socket, err) = listen("tcp, "", port)
> we could fold an error code into our 'socket' class,
> so that you can check the error if you want to, and
> operations on a error-ful socket will continue returning
> the error and/or raise an exception/halt. (I believe
> this is already the case with file and channel, but
> I might be wrong).
Michael, am I missing something, or wouldn't this approach work
against your "productive programmers ignore the error codes and
get a halt; careful programmers pay attention to the error code
and handle it themselves" philosophy espoused in the other thread
(which I like). In particular, it's not likely that I'm going to
ignore the whole socket object being returned, but the routine
will have no way of knowing whether I'm paying attention to the
error or not, right?
And then, more generally, I'm wondering if having a persistent per-socket
error code is more "a good thing" or "an extra field to carry around" (not
being a socket programmer).
-Brad
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
