Hi -
> 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).
Yes and no. To some degree I have two minds about it :)
The listen call is similar to any routine that opens a file
(even though it doesn't open a normal file...it's a file in unix).
So we have the same problem with the open call now - namely,
there's only one return position.
var myfile = open(...);
so if the programmer did not use the optional-error-argument
in the open call, it will halt (today). Even if we had some kind of
check-if-return-value-was-used, a return-error-code-variant
of open would have to return a tuple or encode the error code
in the openned file.
So, there are really 4 options for how 'open' or 'listen' can
return an error:
1) (what we do in open today) error code is an optional out argument,
calls without the optional out argument halt on error.
2) (what Go does) return a tuple of (file, error code) like:
var (myfile, myerror) = open(...);
but it's less clear if we could make the open call halt if the
error code portion of the return value is ignored. It would
be nice if we could do both
var (myfile, myerror) = open(...);
and
var myfile = open(...); // halts on error
Of course, we could just make open and openerr...
3) store the error code in the file/socket record, like:
var myfile = open(...); // saves error code in myfile
var reader = myfile.reader(); // saves error code in reader
reader.read(...); // halts with the error code.
The main disadvantage of this approach is that the error happened
before the spot in which it will be reported. But, since (in our
imaginary future world) read and friends return a 'status' - and
we know at compile time if it was consumed - you can still have
var myint:int;
var ok = reader.read(myint);// consumes error code
reader.read(myint); // halts on error
4) raise an exception
Cheers,
-michael
On 12/12/2013 11:49 AM, Brad Chamberlain wrote:
>
> 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
