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 ?

  • Thanks Travis.
    The inconsistency in the requirement of a using clause, the "compiler" doing little if any checking, and the example code I started with (not a Garmin sample) not using a using clause, all contributed to this problem.
    The fact that the runtime error provides no guidance about where to look for the problem added to the difficulties.
    I did a bit more experimenting after I found what sort of problem I was looking for.
    This statement:

    var bgColor = Graphics.COLOR_BLACK;

    works just fine without a using clause for Toybox.Graphics when it's in a view, or in a view function, and is used in the code that I began with as a model (not a Garmin sample).
    That same declaration causes the runtime error:
    "Could not find symbol Graphics.Failed invoking <symbol>Failed loading application" (exactly as shown) when it is moved to global context without a using clause, and the compiler does not show an error.
    Adding a using clause for Toybox.Graphics gets rid of the runtime error.

    Thanks to everyone for attempting to help.
  • ... and the example code I started with (not a Garmin sample) not using a using clause, all contributed to this problem.


    You want to be careful with any non-garmin samples if you're just starting. Garmin samples have had a few bugs yes, but those are found and fixed quickly, and that's not always the case with code you find on the web.(Just my opinion...)
  • Presumably this is because you use Sys rather than System. I use Gfx rather than Graphics so add:
    using Toybox.Graphics as Gfx;


    gasteropod is correct, but I want to follow up on this so it's clear:

    It's not absolutely necessary to use using statements. If you wanted, you could just specify the full object path for everything, starting at the Toybox level. For example, I could refer to the white color constant asToybox.Graphics.COLOR_WHITE without any using statement, and it would work just fine.

    This gets a little tedious, though, so using statements for any modules an app will use are recommended, just like Travis has stated. A basic using statement use looks something like:

    using Toybox.Graphics;

    This allows the Graphics module and its members to be used in source code without including the whole object path, like Graphics.COLOR_* . Some people prefer to create aliases to modules to make code more readable or shorten long module names. In the case of the Graphics module, you'll often see this:

    using Toybox.Graphics as Gfx;

    Now, the color constants are accessible via Gfx.COLOR_* instead of requiring the full module name. It's important to note that the following are essentially equivalent:

    using Toybox.Graphics;
    using Toybox.Graphics as Graphics;


    If you're using the latter, you can save yourself a few keystrokes.

    There are some exceptions to this using behavior. For example, it's perfectly acceptable to reference Graphics.COLOR_* constants in resource files (and we even let you get away with Gfx.COLOR_* in there) even when the Graphics module is not imported with a using statement in any of your app's source. The reason is that the Rez module includes using statements in its generated code at compile time to handle those automatically.

    We'll follow up on the potential bugs here. I think Travis' report covers everything well.

    Thanks!
  • Thanks for all the clarifications.
  • It's not absolutely necessary to use using statements. If you wanted, you could just specify the full object path for everything, starting at the Toybox level. For example, I could refer to the white color constant asToybox.Graphics.COLOR_WHITE without any using statement, and it would work just fine.

    As I mention in the bug report, this does not work...

    ... If you switch those back and use explicit references (i.e., Toybox.Graphics.COLOR_PURPLE and Toybox.Graphics.COLOR_BLUE), you will note similar problems....


    Travis

  • Yeah, you're correct--that does seem to be broken. :) However, this bug aside, it should work to use explicit references.