B4J Question Project containing bugs: debug and release behavior.

[LucaMs]

Running a project containing bug(s), in debug mode it logs the error and crashes. If you run it in release mode (of course even if you run the jar) no crashes happens.
(I'm attaching a test project. Press on button "Error" and then on button "Toast").

Two questions:

1. is this a design choice? (I believe that any sw for Windows - and other OSs - would crash if it contained a "serious" bug);
2. is this due to the Resumables?

 

[Magma]

hmm... fix

    If lst.IndexOf(100)>-1 Then lst.RemoveAt(lst.IndexOf(100)) ' error!

You mean at compiled continue... ....hmmm ...and you wanna stop ?

 

[LucaMs]

hmm... fix

    If lst.IndexOf(100)>-1 Then lst.RemoveAt(lst.IndexOf(100)) ' error!

You mean at compiled continue... ....hmmm ...and you wanna stop ?

I think that the jar (or exe) should crash.

 

[Magma]

You have a point... i am seeing the same sql update, when inserting... and for example there is a same record with unique field... will ignore.. and no error...

I think that is more design "problem" .. ?

 

[LucaMs]

If lst.IndexOf(100)>-1 Then lst.RemoveAt(lst.IndexOf(100)) ' error!

I purposely entered that error.

 

[Magma]

I know

 

[LucaMs]

I think that is more design "problem" .. ?

I don't know, only Erel can tell us

I don't even know if it is due to the Resumables or not.

 

[Magma]

I think that may be there is java.exe command switch may be stop... but which ?

 

[LucaMs]

I think that may be there is java.exe command switch may be stop... but which ?

It should crash "automatically", without the need for special instructions.

Maybe I'll do a test with VB Net, if it weren't for the problem that... just to create an empty project with this language it takes my PC about 18 years

 

[Magma]

seems like "on error resume next" oldie goldie vb6

but it's setted by default

 

[agraham]

I don't even know if it is due to the Resumables or not.

It is. Just simplify the code and call DoIt directly without the Wait and, importantly, the Sleep so btnErr_Click is no longer a Resumable Sub and it will crash as expected. I agree it seems odd and unintuitive so I looked at the generated code.

    public void start (javafx.stage.Stage stage) {
        try {
            if (!false)
                System.setProperty("prism.lcdtext", "false");
            anywheresoftware.b4j.objects.FxBA.application = this;
            anywheresoftware.b4a.keywords.Common.setDensity(javafx.stage.Screen.getPrimary().getDpi());
            anywheresoftware.b4a.keywords.Common.LogDebug("Program started.");
            initializeProcessGlobals();
            anywheresoftware.b4j.objects.Form frm = new anywheresoftware.b4j.objects.Form();
            frm.initWithStage(ba, stage, 600, 600);
            ba.raiseEvent(null, "appstart", frm, (String[])getParameters().getRaw().toArray(new String[0]));
        } catch (Throwable t) {
            BA.printException(t, true);
            System.exit(1);
        }
    }

The error is trapped by the 'start' method which starts the program. When the error occurs it prints the exception, which I can see in the logs, and calls System.exit which should stop the program - but it doesn't seem to if the error is in a Resumable Sub. One for Erel I think!

 

[LucaMs]

It is. Just simplify the code and call DoIt directly without the Wait and, importantly, the Sleep so btnErr_Click is no longer a Resumable Sub and it will crash as expected.

I can no longer live without Resumables, Wait For, Sleep


More concretely, I can no longer live without money, so you will soon get rid of this crazy member
I think I will soon publish a begging app on GP.

 

[agraham]

It seems this behaviour is just in B4J. I tried in B4A and the app crashes as expected.

 

[LucaMs]

It seems this behaviour is just in B4J. I tried in B4A and the app crashes as expected.

Could it be a design choice for B4J server projects?

However, if Erel could avoid this behavior it would be better.

 

[Magma]

@LucaMs hey... if he do that... all my Apps will crashed !

 

[agraham]

Could it be a design choice for B4J server projects?

I doubt it. Swallowing a runtime error without notification can never be a good idea unless it is explicitly coded with a try...catch. I am intrigued by this behaviour as System.exit should shut down the JVM immediately - the corollary is probably that the error is not propagated to the try...catch in start if it occurs in the contaxt of a Resumable Sub so System.exit is never actually called - though I can't at the moment see anything in the code or decompiled jar that might explain this.

 

[Erel]

It is related to the behavior of the JavaFX engine. Sleep (as many other methods) call Platform.runLater and this method catches exceptions internally.

Note that B4J server apps are indeed configured to catch all exceptions, but it is not related to this issue.

 

[agraham]

this method catches exceptions internally.

That seems to be a rather unfortunate limitation to say the least, and a possibly suspect design decision in the implementation of JavaJX. I'm guessing that even a try...catch in a Resumable Sub will not detect any failure as the exception will be swallowed at a lower level. I'm not impressed

 

[LucaMs]

I have a very simple solution: I will never make mistakes again.

 

[agraham]

If Platform.runLater is swallowing the exception how come it is logged by B4J? Is it because Exception is sub-classed by B4J in which case could the sub-class at least give some runtime notification of a problem?