Bug 65758 - Error not triggered in an "if" statement
Summary: Error not triggered in an "if" statement
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: BASIC (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Macro-StarBasic
  Show dependency treegraph
 
Reported: 2013-06-14 15:50 UTC by gaelle.faurepinel
Modified: 2019-12-30 15:06 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Fix proposal for this bug (23.00 KB, application/vnd.oasis.opendocument.text)
2019-12-30 15:00 UTC, LibreOfficiant
Details

Note You need to log in before you can comment on or make changes to this bug.
Description gaelle.faurepinel 2013-06-14 15:50:25 UTC
When the "error" function is in a "if" statement, it is never triggered.

Example :

In this case, the routine launchs an error :
Sub Main
Dim isErreur as Boolean
isErreur = 1
MsgBox "Essai lancement erreur."
error(9)
MsgBox "Lancement loupé."
End Sub

In this case, it doesn't :
Sub Main
Dim isErreur as Boolean
isErreur = 1
if isErreur then
	MsgBox "Essai lancement erreur."
	error(9)
	MsgBox "Lancement loupé."
end if
End Sub
Comment 1 Julien Nabet 2013-06-21 22:38:53 UTC
On pc Debian x86-64 with master sources updated today and with 4.0.3 Debian packages, I can reproduce this.
Comment 2 Julien Nabet 2013-06-21 23:22:45 UTC
Noel: one for you?
Indeed, when "if" is used, "SbiRuntime::StepERROR()" from basic/source/runtime/runtime.cxx isn't called.

I added a trace in SbiRuntime::Step() for eOp

Situation OK:
Until first MsgBox:
135
135
137
135
129
128
30
135
24
65
25
128

After:
28
135
66
53

Situation KO:
Until first MsgBox
135
135
137
135
129
128
30
135
129
71
135
24
65
25
128

After:
28
135
24
66
25
128
28
135
24
65
25
128
Comment 3 Noel Power 2013-06-24 09:08:33 UTC
sounds like a bug ( and was there in 3.4 afaict )
Comment 4 QA Administrators 2015-03-16 22:51:32 UTC Comment hidden (obsolete)
Comment 5 Buovjaga 2015-03-31 08:40:10 UTC
(In reply to gaelle.faurepinel from comment #0)
> When the "error" function is in a "if" statement, it is never triggered.
> In this case, it doesn't :
> Sub Main
> Dim isErreur as Boolean
> isErreur = 1
> if isErreur then
> 	MsgBox "Essai lancement erreur."
> 	error(9)
> 	MsgBox "Lancement loupé."
> end if
> End Sub

I do get both msgboxes in this case. Does this mean the bug went away?

Win 7 Pro 64-bit Version: 4.5.0.0.alpha0+
Build ID: 8c3cf9dd48e40604867d3a28bddaccd65142df17
TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2015-03-27_15:15:18
Locale: fi_FI
Comment 6 gaelle.faurepinel 2015-03-31 09:56:55 UTC
(In reply to Beluga from comment #5)
> (In reply to gaelle.faurepinel from comment #0)
> > When the "error" function is in a "if" statement, it is never triggered.
> > In this case, it doesn't :
> > Sub Main
> > Dim isErreur as Boolean
> > isErreur = 1
> > if isErreur then
> > 	MsgBox "Essai lancement erreur."
> > 	error(9)
> > 	MsgBox "Lancement loupé."
> > end if
> > End Sub
> 
> I do get both msgboxes in this case. Does this mean the bug went away?
> 
> Win 7 Pro 64-bit Version: 4.5.0.0.alpha0+
> Build ID: 8c3cf9dd48e40604867d3a28bddaccd65142df17
> TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2015-03-27_15:15:18
> Locale: fi_FI

No, if the bug went away, the "error" function would be launched and the script should stop after the first MsgBox with an error message.
Comment 7 gaelle.faurepinel 2015-03-31 10:00:23 UTC
Tested on LibreOffice 4.4.1.2, Ubuntu 14.10 x86-64 : bug still there.
Tested on LibreOffice 3.3.0, Ubuntu 14.10 x86-64 : bug already there -> change "Version" to "Inherited From OOo".
Comment 8 tommy27 2016-04-16 07:22:34 UTC Comment hidden (obsolete)
Comment 9 QA Administrators 2017-05-22 13:21:37 UTC Comment hidden (obsolete)
Comment 10 Buovjaga 2019-08-11 10:53:18 UTC
Still not stopping execution

Arch Linux 64-bit
Version: 6.4.0.0.alpha0+
Build ID: 37fc9f51a8de11d40632e8cda17ccf1fa4b1f503
CPU threads: 8; OS: Linux 5.2; UI render: default; VCL: gtk3; 
Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US
Calc: threaded
Built on 6 August 2019
Comment 11 himajin100000 2019-09-17 20:12:19 UTC
Still unclear about the cause, but I did translation

OK:

STMT
STMT
LOCAL
STMT
FIND
RTL
PUT
STMT
ARGC
SCONST
ARGV
RTL
GET
STMT
CONST
LSET

KO :

STMT
STMT
LOCAL
STMT
FIND
RTL
PUT
STMT
FIND
JUMPF
STMT
ARGC
SCONST
ARGV
RTL
GET
STMT
ARGC
CONST
ARGV
GET
STMT
ARGC
SCONST
ARGV
RTL
Comment 12 himajin100000 2019-09-18 02:32:41 UTC
Seems I was skipping BWRITE, and LSET was wrong. 53 was ERROR
Comment 13 Julien Nabet 2019-09-18 20:36:47 UTC
It seems we enter in https://opengrok.libreoffice.org/xref/core/basic/source/comp/loops.cxx?r=ab9b67bb#28 when KO but not when OK.

But impossible for me to know why since parsing process is too complicated for me.
(uncc myself)
Comment 14 himajin100000 2019-09-19 21:24:51 UTC
still not sure about what to do, but it seems....

There is two different uses of the term "Error"

* "Error Statement" that causes execution stop

and

* Error Function, which returns the error messsage
https://opengrok.libreoffice.org/xref/core/basic/source/runtime/methods.cxx?r=28fc9860#191

like this
Msgbox(Error(9))

no wonder even if error function(in my definition, not the reporter's) does not stop execution. I agree that this is very confusing, though. 

--
in OK case, Peek() used is the following one.

https://opengrok.libreoffice.org/xref/core/basic/source/comp/parser.cxx?r=587ac01f#323

in KO case(Error is used in a IF statement), this Peek() is called after Parse() is returned.

I'm not sure if Peek() called inside Parse() as in OK case would affect this case. 

https://opengrok.libreoffice.org/xref/core/basic/source/comp/loops.cxx?r=ab9b67bb#49

Also let me note that Next() called in Parse() after the Peek() as in OK case resets ePush to NIL. it's still unclear to me this is important in fixing this bug.
Comment 15 LibreOfficiant 2019-12-30 15:00:39 UTC
Created attachment 156854 [details]
Fix proposal for this bug

I have tried to synthetize what's existing in some Basic-like languages into a sound improvement.
Comment 16 LibreOfficiant 2019-12-30 15:06:54 UTC
(In reply to LibreOfficiant from comment #15)
> Created attachment 156854 [details]
> Fix proposal for this bug
> 
> I have tried to synthetize what's existing in some Basic-like languages into
> a sound improvement.

The main idea is to distinguish between Error statement and Error function. And make sure Basic code blocks have no impact on Error variants.

A collateral would be to add extra features to the Error statement, which can be phased separately.