Bug 148466 - Basic Choose() function errors are trapped inconsistently
Summary: Basic Choose() function errors are trapped inconsistently
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: BASIC (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
Whiteboard: target:7.4.0
Depends on:
Blocks: Macro-StarBasic
  Show dependency treegraph
Reported: 2022-04-08 11:41 UTC by Alain Romedenne
Modified: 2022-12-01 17:33 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:
Regression By:


Note You need to log in before you can comment on or make changes to this bug.
Description Alain Romedenne 2022-04-08 11:41:34 UTC
Missing or omitted expressions arguments - of Choose() method - are not properly caught.

Steps to Reproduce:
Consider the following routine:
Sub demo
    Print Choose(),
    Print Choose(5)
    MsgBox Choose(2, "a",, 15) ' Should raise Error #13 as in VBA
End Sub

Actual Results:
1. 1st Print statement raises error #5
2. 2nd Print statement raises error #13
3. MsgBox statement displays "Error 448" 

Expected Results:
Using VBA, results are different:

1. is rejected by VBA compiler
2. raises error #94
3. raises error #13

Reproducible: Always

User Profile Reset: No

Additional Info:
VBA Choose() function doc:
Comment 1 Mike Kaganski 2022-04-11 09:51:39 UTC
I do not quite see, which is the *expected* result - hence, I fail to see what exactly is considered wrong.

(In reply to Alain Romedenne from comment #0)
> Expected Results:
> Using VBA, results are different:

Is the "Using VBA, results are different" the whole essence of the report? Then it looks NOTABUG to me: there's no definition in language or function *specification* what should be the error code in which situation. Even in VBA mode, we don't generally have the same errors (even compile-time vs runtime!).

Additionally, the bug report does not mention if this is a request for a change for the sake of change, or if there is some existing code that fails working when importing from MSO. I suspect that this is only created as part of documentation effort, not motivated by a real user problem.

However, *iif* there's not much effort is required to ensure that the errors *in VBA mode* (only!) follow VBA, then it's fine to implement this. However, note the "in VBA mode": the concern about the specific error numbers can only arise when a code is written with specific errors expectation and handling; and this very expectation is applicable to existing StarBasic code; so if we introduce *such* changes just to keep some (which?) existing VBA code working on migration, we definitely must protect our existing users from the same problem.
Comment 2 Mike Kaganski 2022-04-11 10:06:30 UTC
For comparison: I read many API docs in MSDN. There it is common for functions to *not* specify any specific error codes that the function *may* return in case of error (e.g., it is common to see "On error, the return value is 0. To get extended error information, call GetLastError", without any mapping of input values to error codes - e.g. [1]); or it may choose to document *some* possible error codes for important cases (that actually are needed for reasonable use of the API), and *also allow other codes* (e.g., [2]).

IMO, the error codes are *to the greatest possible extent* are implementation detail, which should evolve together with improvements of the IDE. Trying to fix these would make them part of published API, which is binding, and *must be avoided as much as possible*.

[1] https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-movefileexw
[2] https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-movefiletransacteda
Comment 3 Alain Romedenne 2022-04-25 15:53:00 UTC
This is an enhancement request to Basic Choose() method in the context of LibO Basic runtime:

- Whenever one expression is omitted such as in
Sub demo
    MsgBox Choose(2, "a",, 15)
End Sub

I suggest to return Null instead of "Error 448". Such return value would match that of 'index' argument when out of boundaries values are given.

PS: You may forget VBA compatible behaviour
Comment 4 Commit Notification 2022-05-09 15:44:46 UTC
Alain Romedenne committed a patch related to this issue.
It has been pushed to "master":


tdf#141474 tdf#148466 Choose function accepts keyword arguments