Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #12830 > unrolled thread

Strange Socket Problem Solved!

Started byKnute Johnson <nospam@knutejohnson.com>
First post2012-03-09 19:13 -0800
Last post2012-03-10 16:55 -0800
Articles 3 — 2 participants

Back to article view | Back to comp.lang.java.programmer


Contents

  Strange Socket Problem Solved! Knute Johnson <nospam@knutejohnson.com> - 2012-03-09 19:13 -0800
    Re: Strange Socket Problem Solved! Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-03-10 13:46 -0800
      Re: Strange Socket Problem Solved! Knute Johnson <nospam@knutejohnson.com> - 2012-03-10 16:55 -0800

#12830 — Strange Socket Problem Solved!

FromKnute Johnson <nospam@knutejohnson.com>
Date2012-03-09 19:13 -0800
SubjectStrange Socket Problem Solved!
Message-ID<jjegsf$746$1@dont-email.me>
I want to thank everybody that gave me ideas to help me find my problem 
with my program.  It turns out that the problem was bad data throwing a 
RuntimeException in the thread, bringing it to a stop.  I probably 
should have programmed it with bad data in mind but I didn't.  We had an 
agreement on format and that was supposed to be that.  I had some simple 
format checks but no protection for the Exception.

I haven't seen the actual bad record yet but I put in traps for it and 
will have the offender soon.

Thanks again everybody.

-- 

Knute Johnson

[toc] | [next] | [standalone]


#12856

FromDaniel Pitts <newsgroup.nospam@virtualinfinity.net>
Date2012-03-10 13:46 -0800
Message-ID<IYP6r.31308$Ai4.9849@newsfe18.iad>
In reply to#12830
On 3/9/12 7:13 PM, Knute Johnson wrote:
> I want to thank everybody that gave me ideas to help me find my problem
> with my program. It turns out that the problem was bad data throwing a
> RuntimeException in the thread, bringing it to a stop. I probably should
> have programmed it with bad data in mind but I didn't. We had an
> agreement on format and that was supposed to be that. I had some simple
> format checks but no protection for the Exception.
>
> I haven't seen the actual bad record yet but I put in traps for it and
> will have the offender soon.
>
> Thanks again everybody.
>
The lesson here should be that any "infinite loop" that you want to 
truly be infinite should have a "catch RuntimeException" inside of it. 
Unless you want an exception to end the loop. The nature of 
RuntimeException is that you never know what downstream code is going to 
throw it, and should be willing to handle it if you need to.

On the other hand, "Bad data" should probably through a checked 
exception.  I often try to differentiate checked vs unchecked as 
"Something that I have no control of, but should be reported", vs 
"Indication of a bug in the code."  Of course, this isn't always the 
case, but often should be.

[toc] | [prev] | [next] | [standalone]


#12857

FromKnute Johnson <nospam@knutejohnson.com>
Date2012-03-10 16:55 -0800
Message-ID<jjgt5h$c9e$1@dont-email.me>
In reply to#12856
On 3/10/2012 1:46 PM, Daniel Pitts wrote:
> On 3/9/12 7:13 PM, Knute Johnson wrote:
>> I want to thank everybody that gave me ideas to help me find my problem
>> with my program. It turns out that the problem was bad data throwing a
>> RuntimeException in the thread, bringing it to a stop. I probably should
>> have programmed it with bad data in mind but I didn't. We had an
>> agreement on format and that was supposed to be that. I had some simple
>> format checks but no protection for the Exception.
>>
>> I haven't seen the actual bad record yet but I put in traps for it and
>> will have the offender soon.
>>
>> Thanks again everybody.
>>
> The lesson here should be that any "infinite loop" that you want to
> truly be infinite should have a "catch RuntimeException" inside of it.
> Unless you want an exception to end the loop. The nature of
> RuntimeException is that you never know what downstream code is going to
> throw it, and should be willing to handle it if you need to.
>
> On the other hand, "Bad data" should probably through a checked
> exception. I often try to differentiate checked vs unchecked as
> "Something that I have no control of, but should be reported", vs
> "Indication of a bug in the code." Of course, this isn't always the
> case, but often should be.

All true.  It also shows how hard it is sometimes to diagnose a problem. 
  I was sure it was related to a Socket issue because it wouldn't 
reconnect.  I just didn't think through the problem of a 
RuntimeException causing the thread to stop.  And that was partly 
because I didn't think the data was going to be the problem.  We did the 
data format design, the big giant heads talked to the other big giant 
heads and they said the data will come in this format.  Us pinheads 
never planned for the data coming out of format.  So there you go.

-- 

Knute Johnson

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.java.programmer


csiph-web