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.