Re: error handling

Lisa Pearlson wrote:
> "Gerald W. Lester" <Gerald.Lester@xxxxxxx> wrote in message
> news:KeBwf.271595$0l5.186598@xxxxxxxxxxxxx
> > Lisa Pearlson wrote:
> >> Imagine I have a socket read function.. it reads bytes, but if it doesn't
> >> read all bytes in time, a timeout occurs.
> >> I want my function to return all bytes that have been read, but also test
> >> of it is complete or some error occurred.
> >> What's wrong with this code? (it's pseudo code, not real code.. just to
> >> give an example):
> >
> > Short answer: that ain't how TCP/IP works. The read will not timeout
> > until the socket is closed -- unless you are using non-blocking sockets,
> > then it will almost always come up short.
> >
> > TCP/IP reserves the right to chop your outgoing data stream into whatever
> > size packets it wants, it just guarantees you that the bytes will come in
> > the same order sent, not in the same chunks sent. It is your
> > responsibilty to reassemble them.
> >
> > The long answer is more complex.
> >
> >>
> >> proc readsocket {size}{
> >> set data {}
> >> set data [read $socket $size]
> >> if { [string length $r] < $size} {
> >> return -code error -errorinfo {not enough bytes could be
> >> read} $data
> >> }
> >> return $data
> >> }
> >>
> >> Then this can be used this way:
> >>
> >> if { [catch {readsocket 1024} answer]} {
> >> puts "Error: $::errorInfo, partial data: $data"
> >> exit 1
> >> }
> >> puts "Complete data: $data"
> >> exit 0
> >>
> >>
> >>> It's not about TCP/IP. It's 'pseudo' code.. not real.. in actuality I am
> using expect, and I myself expect certain amount of data before I myself
> generate a timeout.
>
> The focus should not be on my pseudocode.. I can come up with a better
> example that actually works, (as I have in my current project), but that
> gives more detail than necessary to illustrate how/when I wish to use
> exceptions to return data (not halt) yet allow additional info.. There are
> other ways I can return data AND additional information, but my question is,
> why not use the mechanism already in place for this?
>
> Lisa
>

First off I want to politely ask Lisa to please not top post (replying
at the top of the quoted message) and put your replies after the quoted
message instead. I rarely ask people to do this and certainly feel
comp.lang.tcl should feel friendly and people should post the way they
feel comfortable. But since this conversation is growing very long it
gets very hard to follow if people keep top posting and I'm getting
tired of cutting and pasting quotes to get them in the right order so
that my reply can be seen in the right context.

OK, sorry for that. Now back on topic. Exceptions are designed
primarily to halt control flow (since control flow is often dangerous
in the presence of an exception). So asking exceptions to not halt
illustrates a misunderstanding of what exceptions are. Passing
information on the cause of exception is only the secondary function of
exceptions.

The mechanism you're trying to use and the mechanism you want are not
the same thing. What you want is plain old returning of value, the so
called 'other ways' are the 'mechanism already in place'. I've already
illustrated to you one way of returning optional information. There are
others like returning a list or setting a global variable.

Back to your example. Why do you think the following version is less
usable?

proc readsocket {size {errinfo ""}} {
global socket
set data [read $socket $size]
if { [string length $data] < $size} {
return [list FAIL $data]
}
return [list OK $data]
}

It is used this way:

lassign [readsocket 1024] status data
if {$status == "FAIL"} {
puts "Error: Partial data: $data"
exit 1
}
puts "Complete data: $data"
exit 0

This is even better because you can also catch failed socket operations
for example connection reset by peer:

if {[catch [readsocket 1024] retval] != 0} {
puts "Error: $retval"
exit -1
}
lassign $retval status data
if {$status == "FAIL"} {
puts "Error: Partial data: $data"
exit 1
}
puts "Complete data: $data"
exit 0

.

Relevant Pages

  • Re: Close a blocked socket
    ... from any other informational exceptions that occur in .NET. ... discards the socket, and the program code finds out about it the hard way. ... With 30 connections it ... I didn't "decide to go blocking". ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: API Design: Is Socket.Select() seriously busted?
    ... outcomes-also causes inefficiencies because catching and handling exceptions ... directly from VS2005 help for Socket class: ... Win32 Winsock there was no need for using error trapping when responding to ...
    (microsoft.public.dotnet.languages.csharp)
  • [9fans] APE and listen(2B)
    ... seems to somehow exit the actual listenproc, ... socket accept: Invalid argument ... int main { ... perror; ...
    (comp.os.plan9)
  • Re: return in void functions
    ... Tripling the number of exit points per function almost ... >>triples the time it takes to debug a problem. ... > easier to use and works with multiple returns and exceptions. ... > really related to multiple exit points, ...
    (comp.lang.cpp)
  • Re: socket calls send recv error handling questions
    ... There should not be any exceptions thrown from socket calls, ... example, that after you recva command the next recv, which gets some ... The WinSock calls don't throw C++ exceptions. ... My fear is that a heavy traffic network could ...
    (microsoft.public.windowsce.embedded.vc)