I can appreciate
            both your points.  A fair compormise would be to intoruce a
            reasonable defualt time out for queries that throws a
            runtime exception which would be handled in a similar manner
            as an NPE (i.e. not java.concurrent.TimeoutException). 
            Though, there still the thorny question of what is a
            reasonable timeout period.
            Cheers,
            Pawel
            
            On 07/17/2012 11:49 AM, Cortell John-RAT042 wrote:
         
        
          End-users
              who have to resort to ‘kill’ or Task Manager after much
              cursing will likely have a different take. A program that
              becomes completely unresponsive or that crashes is
              probably the most frustrating thing a user can experience,
              particularly when there’s unsaved work at stake.
           
          This
              is the second time in the last year or so that I’ve heard
              this interesting perspective: if you allow the symptom of
              a bug/error-situation be as bad as it can be (a hang, a
              crash), developers will be more likely to notice it and
              more motivated to fix it. (The first was on a discussion
              of parameter validation in C/C++ code). It seems to me
              that position is reasonable when you’re talking about
              issues you know for sure will reproduce at development
              time. But there’s no way to ensure all possible failure
              scenarios are seen during development, thus I personally
              don’t think it’s acceptable to knowingly allow a crash or
              hang.
           
          Anyway,
              that’s my two cents.
          John
           
          
            
             
            My personal
              preference is to have a frozen UI since it forces
              developers to fix it fast.  
              
              
              
             
           
          
            
            
            
          _______________________________________________
          cdt-dev mailing list
          cdt-dev@xxxxxxxxxxx
          https://dev.eclipse.org/mailman/listinfo/cdt-dev