Errors, Documentation, Runtime failures .....

I am inching forward building a very simple, experimental app using Eclipse.
I had a couple of basic screen drawing functions working.... a couple of lines, and a bit of text.
I moved some variables around, and began getting
"Could not find symbol Graphics.Failed invoking <symbol>Failed loading application"
at RUN TIME.

NOT at compile time..... no errors at "compile" time.
I searched the documentation for descriptions of errors and cannot find any description of this.
The error does not point at any line in the source, nor does it name a function.

I have now commented out ALL of the operational code that touches those variables... and everything else in the related functions other than Sys.println() calls, and the error persists.

So..... assuming that there's some kind of typo lurking in my source now...
1) Why doesn't the compiler flag it ?
2) If there's a runtime error, why doesn't it describe the function that it's occurring in ?
3) Where is there documentation about these kinds of errors ?

What DOES the compiler catch in the way of errors, and what kinds of errors get by and therefore make your app prone to crashing at runtime ?

  • Post the line where you get the error, Are you using Graphics as your own thing, or are you using Toybox.Graphics?
  • If I got any indication of where the error was occurring, I'd be able to sort it out.
    There is no indication of what line the error occurs in, no indication of what function it occurs in, and my println() functions never execute, though they are placed before anything else is called in the functions involved..... I'll be posting an update with a new discovery in a minute.
  • And... the forum seems to have some issue.
    I've tried several times to add an update here and I get an error that says "Error while saving content: SyntaxError: Unexpected token in A in JSON at position 1"
    ???
    So... is there text that cannot be posted in this forum ?
  • To RaceQs....
    Thanks for the thought.
    The third line in the source is:
    using Toybox.System as Sys;
  • There's something weird: to use Sys you have to declare
    using Toybox.System as Sys;
    but to use Graphics, youdon't have to declare
    using Toybox.Graphics as Graphics;
    maybe it's worth a try?

  • Thanks once again.
    I back-tracked until I had code that no longer showed the error, then inched forward again.
    The problem was that I had done the following:

    class View1 extends Ui.view
    {
    var bgColor = Graphics.COLOR_BLACK;

    This works within a function, but not in the class declaration.
    Why is unclear to me, and the fact that the compiler doesn't call it an error, if it's going to be an error at run-time, is truly amazing to me.

    The other thing I discovered is that the simulator provides no indication that the app has run when this error occurs, yet when I kill the simulator, the app is apparently still "running" as far as the development environment is concerned... that leads to.... changing the sources, recompiling, and attempting another test results in NOT running the new code.
    The fact that killing the simulation doesn't kill the app code sufficiently to run another test is equally amazing to me.

    Thanks for trying to help.
    Moving on.
  • What was your "using" line for Graphic and was it in the .mc with this code?
  • What DOES the compiler catch in the way of errors, and what kinds of errors get by and therefore make your app prone to crashing at runtime ?

    For the most part, MonkeyC is not checked at compile time. When you reference a variable, it is looked up at runtime. If that variable isn't found or isn't of the right type, things go boom. This is like most other duck-typed languages (e.g., python, javascript), but is foreign if you come from a statically-typed language (e.g., C/C++/Java).

    The resource files are checked to see if they match the schema. When when you extend a class, the base class is checked as well. I can't think of many other things that the compiler cares about. Everything else is checked at runtime.

    If you are referencing a module in your code, you should have a using clause to bring that modules names into scope. It appears that you don't always need to do this; you can get away with it if you use the names inside of functions, but it can explode if you use them at class or module (global) scope. It could be a bug that the behavior is inconsistent, but I'll let the folks at Garmin decide that one.

    I'll cook up a quick testcase to demonstrate the problem.

    Travis
  • There's something weird: to use Sys you have to declare
    using Toybox.System as Sys;
    but to use Graphics, youdon't have to declare
    using Toybox.Graphics as Graphics;
    maybe it's worth a try?



    Presumably this is because you use Sys rather than System. I use Gfx rather than Graphics so add:
    using Toybox.Graphics as Gfx;
  • Yes.

    The bottom line is that users should always have a using clause for modules that are referenced in a given source file. If using an alias for a module (e.g., Gfx), then that alias must be specified with with the complete using clause with the as keyword. If using the module's actual name (e.g., Graphics), then the alias is not necessary.

    I posted an issue in the Bug Reports forum with a testcase. I'm not sure how much attention it will get, but it does seem like something that should be looked into.

    Travis