[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Exception and selector performing

From: stefan
Subject: Re: Exception and selector performing
Date: Tue, 10 Aug 2004 13:52:29 +0200
User-agent: Internet Messaging Program (IMP) 3.2.2

Citát Richard Frith-Macdonald <address@hidden>:

> On 8 Aug 2004, at 20:18, Stefan Urbanek wrote:
> > Additional information ...
> >
> > On 2004-08-08 21:13:41 +0200 Stefan Urbanek <address@hidden> 
> > wrote:
> >
> >> Hi,
> >> Here is the situation: I have DO connection: [Observer] <-----> 
> >> [Server]. I do:
> >> 1. send oneway message from Observer to Server
> >> 2. server does something and uses
> >>     performSelectorOnMainThread:@(notyfyObserver)
> >>     withObject:self
> >>     waitUntilDone:NO'
> >> 3. 'notifyObserver' is run in server and it sends a message to 
> >> Observer
> >> 4. when there is an exception in an observer method it is swallowed
> >> And (4.) is the problem, as it is really dificult to debug any 
> >> application if there is an exception. How do I know that there was an 
> >> exception?
> >
> > All used observer methods are oneway, what explains why the exception 
> > is ignored. However, there is no feedback at all. At least some 
> > message shold be printed or something.
> As the method is oneway, there is no way that exceptions can be 
> propagated back to the  process which sent the message.
> Perhaps we can/should change GNUstep to log these exceptions ... but 
> I'm not sure it's really worthwhile.  If MacOS-X does this, I'd change 
> the current behavior to improve compatibility, but otherwise I don't 
> think it should be changed.

Not sure about OSX, but I think that the exception should be somewhere logged
because "something went wrong there" in the application. At least it should be
available optionally if not turned on by default. I've spent lots of time
finding those invisible bugs as I had unexpected behaviour in different parts
of the application than the bug happened.

> For the purposes of debugging softwaqre you are working on the solution 
> is trivial ... just use an exception handler in the observer method to 
> trap any exceptions and print an error message.

If it was only one method (and it is not), then it would be ok to handle
exception there. I'll try for this time, as there is no other solution for

BTW. what it has to do with OSX behaviour? Regardless of OSX, any
error/unexpected behaviour report from an application can lead to improvement.
It is not behavioural/structure/interface issue, it is informational issue -
whether to give more information or not. Maybe I am wrong, but i see no reason
for incompatibility if we had such feature and OSX not.

Stefan Urbanek

reply via email to

[Prev in Thread] Current Thread [Next in Thread]