avoid workarounds!

[Stefan Westerfeld]

   Hi!

On Sat, Feb 08, 2003 at 03:16:16PM +0100, Carsten Pfeiffer wrote:
> On Friday 07 February 2003 10:55, Stefan Westerfeld wrote:
> 
> > I was recently greeted with the message
> >
> > | On last startup, KNotify crashed while creating Arts::Dispatcher. Do you
> > | want to try again or disable aRts Sound output?
> >
> > on login. Could you _please_ not try to spend work on fixing the symptoms
> > but on fixing the problems?
> >
> > Kludging workarounds in higher-level stuff for broken lower-level stuff is
> > ineffective, hides the real source of the problems and should not be done.
> > If aRts crashes, it should be fixed, and not the program using aRts (which
> > is impossible to do while keeping the featureset it was using aRts for in
> > the first place anyway).
> 
> In general, I agree with that, but KNotify is a special case. It's an 
> application that is automatically started and not just once, but e.g. 
> whenever a window pops up. A crashing KNotify makes your entire KDE system 
> _unusable_. That's inacceptible, sorry.
> 
> I think there would be less such problems if there was better error handling 
> instead of assert() in arts.

In general, there is error handling in aRts. For instance, if you can't
connect a server, a connection drops or authentication fails you should not
run in an assert, but be able to see with .isNull() that something went
wrong. I generally only want use assert for programming errors, i.e. for
"can't happen" situations.

In the concrete context we're discussing (knotify), it would be absolutely
great if you could tell me

 - knotify did this and that
 - aRts crashed in this and that assert
 - this is due to a situation that _can_ happen
 - thus I expect error handling to be changed in such and such way

We can then still discuss to keep the temporary workaround, if the real issue
can't be fixed quickly, but its absolutely important that the information
whats the source of the problem and how it really should be fixed doesn't get
lost. Otherwise the same type of workaround will be necessary again and again.

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan at space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-