On Wed, Sep 8, 2010 at 2:58 PM, Ross Finlayson <span dir="ltr"><<a href="mailto:finlayson@live555.com">finlayson@live555.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div class="im">
<blockquote type="cite"><font face="Tahoma" size="-1">I am
suggesting the call to abort() in the function
BasicTaskScheduler::SingleStep() at line 95 in BasicTaskScheduler.cpp
to be replace with something that is less destructive (C++ exception?)
since a socket error can happen for legitimate reasons (remote closed,
...).</font></blockquote>
<div><br></div>
</div><div>Perhaps, although my intention for this call to "abort()"
(and others in the code) was that it be a "should never get
called" situation. The preceding "if" statement
is supposed to catch the small set of error codes that we expect to
see in this situation.</div>
<div><br></div>
<div>So, my question is: What specific error code(s) are you seeing in
this situation? (Also, are you running Windows, or a Unix
system?)</div></div></blockquote><br>
IMO, it's generally bad form for a _library_ to call abort() or exit(); it basically means some internal library error is more
important than anything that could possibly be going on in the actual
application, which is highly unlikely. Our application does a lot more
than just stream video; to have our RTSP server library drop the whole
process is a pretty thuggish method to communicate failure. These calls
should be reserved for application code itself. I think you're
better off A) attempting to recover or B) crashing outright or C)
returning some error to the application or even D) doing nothing.<br>
<br>
I would not consider using C++ exceptions, they're an architectural
disaster in my not-so-humble opinion (and particularly so with embedded platforms, there are a few "gotchas," see
<a href="https://developer.mozilla.org/en/C___Portability_Guide">https://developer.mozilla.org/en/C___Portability_Guide</a> for more info).