Re: Review Request 127501: Improve TCPSlaveBase::isConnected

2016-03-31 Thread Albert Astals Cid
> On March 27, 2016, 10:03 a.m., David Faure wrote: > > Given how the socket API works, you should only call error() after a call > > that returns false (e.g. waitForConnected, etc.). As you found out, calling > > error() at random points in time doesn't give useful information, you get > >

Re: Review Request 127501: Improve TCPSlaveBase::isConnected

2016-03-31 Thread Albert Astals Cid
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127501/ --- (Updated March 31, 2016, 8:01 p.m.) Status -- This change has been

Re: Review Request 127501: Improve TCPSlaveBase::isConnected

2016-03-31 Thread David Faure
> On March 27, 2016, 10:03 a.m., David Faure wrote: > > Given how the socket API works, you should only call error() after a call > > that returns false (e.g. waitForConnected, etc.). As you found out, calling > > error() at random points in time doesn't give useful information, you get > >

Re: Review Request 127501: Improve TCPSlaveBase::isConnected

2016-03-28 Thread Albert Astals Cid
> On March 27, 2016, 10:03 a.m., David Faure wrote: > > Given how the socket API works, you should only call error() after a call > > that returns false (e.g. waitForConnected, etc.). As you found out, calling > > error() at random points in time doesn't give useful information, you get > >

Re: Review Request 127501: Improve TCPSlaveBase::isConnected

2016-03-28 Thread Albert Astals Cid
> On March 27, 2016, 10:03 a.m., David Faure wrote: > > Given how the socket API works, you should only call error() after a call > > that returns false (e.g. waitForConnected, etc.). As you found out, calling > > error() at random points in time doesn't give useful information, you get > >

Re: Review Request 127501: Improve TCPSlaveBase::isConnected

2016-03-27 Thread David Faure
> On March 27, 2016, 10:03 a.m., David Faure wrote: > > Given how the socket API works, you should only call error() after a call > > that returns false (e.g. waitForConnected, etc.). As you found out, calling > > error() at random points in time doesn't give useful information, you get > >

Re: Review Request 127501: Improve TCPSlaveBase::isConnected

2016-03-27 Thread Andreas Hartmetz
> On March 27, 2016, 10:03 a.m., David Faure wrote: > > Given how the socket API works, you should only call error() after a call > > that returns false (e.g. waitForConnected, etc.). As you found out, calling > > error() at random points in time doesn't give useful information, you get > >

Re: Review Request 127501: Improve TCPSlaveBase::isConnected

2016-03-27 Thread Albert Astals Cid
> On March 27, 2016, 10:03 a.m., David Faure wrote: > > Given how the socket API works, you should only call error() after a call > > that returns false (e.g. waitForConnected, etc.). As you found out, calling > > error() at random points in time doesn't give useful information, you get > >

Re: Review Request 127501: Improve TCPSlaveBase::isConnected

2016-03-27 Thread David Faure
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127501/#review94042 --- Given how the socket API works, you should only call error()

Re: Review Request 127501: Improve TCPSlaveBase::isConnected

2016-03-26 Thread Andreas Hartmetz
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127501/#review94033 --- Ow. That's a pretty bad problem. I suggest a less intrusive