Documents that are to large for the memory available will also fail to
load in the 1st approach.
To add array review mechanism is in my opinion only a source of errors.
I think STL should be used.
+1 for not hiding the exceptions. Maybe we could catch exception on
document level quickly and process the directly?
On 25.03.2018 16:21, Patricia Shanahan wrote:
Currently, AOO uses a lot of finite size arrays. Ideally, overflows
will be detected and lead to an error message, but that still prevents
processing of the user's documents.
Computer memories and swap spaces are still increasing in size, so the
array size limits are more likely to be the limiting factor on
document sizes.
I can see two main strategies, but I'm open to additional suggestions.
1) Keep the finite size arrays, but periodically review them to see if
the sizes should be increased.
2) Use automatically extending STL structures. If a document is too
big or uses too many instances of some array element, the symptom will
be the process as a whole running out of memory. We would have to make
sure all memory allocation failures are handled smoothly.
This somewhat ties in with exception handling strategy. As we turn
what used to be silent out-of-bounds conditions into exceptions, it is
important to avoid arbitrary catching and hiding of all exceptions.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
