Re: Continuing Mulberry-Windows issues
Kenneth Porter <[email protected]> Fri, 05 May 2023 11:42:52 -0700
| Newsgroups | gmane.mail.mulberry.user |
|---|---|
| Message-ID | <1DF3F73452A27A74BF440444@[10.96.7.39]> |
--On Friday, May 05, 2023 2:41 PM -0400 John C Klensin <[email protected]> wrote: > These look like different errors to me and I have to admit I > have no idea what "Throw" or "Catch" mean in this context. I suspect these can't be fixed without major surgery. I've seen the code and it's quite hard to follow. One issue I ran into early is that Windows code should try to run all its GUI logic in thread 1 but Mulberry started as a Mac program and often tries to do GUI stuff in the worker threads, and that has led to crashes. The "throw" and "catch" are programming things. Old code would return error codes when something went wrong. Newer code "throws" an object with potentially complex information, like the name of the object (which is what went wrong) and data associated with the error. Higher levels of the stack can "catch" an exception and either do something about it, pass a different exception with a different name with higher-level meaning, or just pass the low level exception on. You'll see this idiom called try/catch, because the catch applies to a whole block of code inside a try clause, and the throw is the line that reports an error. Like this: try { it_failed = do_something(); if (it_failed) throw WhyItFailed; } catch (WhyItFailed) { throw do_something_did_not_work; } The exceptions you're seeing are out_of_range and CFileException. The first one is usually a bad array index, like trying to access one more item than an array actually has. That's often because one thread took an item off the end while another thread was walking through the array looking at each item, and they didn't coordinate their accesses. The file exception could be attempting to access a file that doesn't exist, or writing to a directory where one lacks permissions. Something file-related, in other words. c0000005 errors are memory access errors, and mean an attempt to read or write memory that the program shouldn't. Which usually means a bad pointer, often because the program got rid of an internal object and then tried to access it again.