In our previous episode, Mattias G?rtner said: > > > What should happen when an exception occurs? > > > > AFAIK any unhandled exception in a thread will cause it to silently die > > Yes, and that should never happen. At least not for normal exceptions like out > of memory, index out of bounds, io error - anything that does not corrupt the > heap. > I'm catching any exception. But somehow the exception must be delegated to the > group's starter thread. (which is not necessarily the process' main thread).
I do not get this? Why is this so logical to route this to the starters thread? There are two problems with that: - the starter thread can be pretty much everywhere in its codepath. Not necessarily the place where the thread was started. - It assumes some form of polling/synchronization and essentially event-driven behaviour. > > > It would be nice if the exception can be transfered to the main thread. > > > Is this possible? How? > > > > I don't know, set a flag in the thread and check it periodically from > > the main thread? > > I do that already. > My current idea is to simply pass the exception object to the other thread and > raise it there. But I'm not sure if this works always. Maybe I have to set > some > more RTL values to do that cleanly. More logically, have a tthread.onexception that can handle the exception, if not already there. It can then pass it to whatever thread or subsystem necessary using custom synchronization. > > (Florian's suggestion does the reverse: raise in a thread an exception > > occurred while executing in the context of the main thread) > > Yes, but 'synchronize' is only for the process' main thread. Yes, and that might not be event-driven either (that is not a requirement for using tthread, only for synchronization), so IMHO that is false, and never should be default behaviour. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel