×

Discussion Board

Results 1 to 8 of 8
  1. #1
    Registered User
    Join Date
    Jan 2004
    Location
    Poland
    Posts
    49

    phone's screen as error console

    is there any possibility using actual phone, not emulator - to redirect printStackTrace() anywhere else than standard output stream - like System.setOut() in J2SE? My app runs smooth on emulator and crashes on phone - I do not see any way to check what's going on, just a clue - it has sth to do with networking (happens while loading from server).

  2. #2
    Registered User
    Join Date
    Mar 2003
    Location
    Zurich, Switzerland
    Posts
    16
    i do it the obvious way - and it's often good enough: add a

    public static String errString = null;

    to your active Canvas class and
    add to its paint() method:

    if (errString != null) {
    g.translate(-g.getTranslateX(),-g.getTranslateY());
    g.setClip(0,0,getWidth(),getHeight());
    g.setColor(0xff0000);
    g.drawString(errString,0,0,Graphics.TOP|Graphics.LEFT);
    }


    feels a bit clunky but does the job - for the release you can take it out again. fill your errString when desired (in a catch or elsewhere).

    fin

  3. #3
    Registered User
    Join Date
    Jan 2004
    Location
    Poland
    Posts
    49
    Thanks for a quick reply.
    My first impression - you showed a way to display a message on a screen, any message, but my concern is a specific message which is (I guess sadly) unreachable during actual phone's runtime - i.e. standard output stream's content. It should be redirected first somehow to be available for display and there are no predefined functions in J2ME to do so.
    Maybe someone have seen any library class adding such capabilities???

  4. #4
    Regular Contributor
    Join Date
    Aug 2003
    Location
    uk
    Posts
    232

    slightly more fool proof method

    Code:
    static String sErrorBuf = "";
    
    public static void LogError(String err)
    {
    	if (sErrorBuf.length() > 0)
    		sErrorBuf = sErrorBuf + ":" + err;
    	else
    		sErrorBuf = err;
    
    	System.err.println("ERR:" + err );
    }
    
    // Then in my games main menu the following code:
    
    if (MyUtils.sErrorBuf.length() > 0)
    {
    	theMenu.setTicker(new Ticker(MyUtils.ErrorBuf));
    	MyUtils.sErrorBuf = "";
    } else {
    	theMenu.setTicker(null);
    }
    
    // the reason I store errors and display them in the
    // menu with a ticker, is the display often changes
    // and the canvas you draw an error to could change
    // at any moment, thus meaning you don't get to see
    // the error message on a real phone, but by storing
    // it and adding it as a ticker, you always do, it can also
    // cope with long error strings.

  5. #5
    Registered User
    Join Date
    Jan 2004
    Location
    Poland
    Posts
    49
    Hi alex

    And again not the problem is error message display, but redirecting Throwable.printStackTrace() to be available anywhere else than standard output (System's out - PrintStream), because (my guess) standard output stream communicates are ignored and unavailable in most if not all actual phones.
    I might be wrong providing your MyUtil is a kind of class that can redirect that stream - can I get it somewhere then?

    Besides whole matter - I only read about such differences between actual phone and emulator - do you know any sources that list such diffs, especially dealing with networking?

  6. #6
    Super Contributor
    Join Date
    Mar 2003
    Location
    Israel
    Posts
    2,280
    There are no documented ways to access the console output for MIDlets. It doesn't necesarilly mean that the console output is ignored, just that there is no way to get it from Java. For example, on Sony phones you can view the console output from the phone on your computer using their tools; and I've heard of using AT commands and hyperterminal to capture the console output from Motorolas. I don't know about anything like this for Nokia phones and I haven't heard of using code in the MIDlet to capture it in any case.

    shmoove

  7. #7
    Regular Contributor
    Join Date
    Aug 2003
    Location
    uk
    Posts
    232
    The way I see it, there are 3 types of generated stdout/stderr in most programs:

    1: System.err.println(m);
    // used anywhere

    2: e.printStackTrace();
    // used in exception handlers

    3: Error messages that come from inside some of the standard libraries.
    // anywhere you have not handled an error usually

    As far as I know, you cannot capture or redirect either.
    If you had the source code to the System library you might be able to do it, but I suspect its unlikely.

    What you do know, is where [1] and [2] are used.

    The first thing todo, is stop using println and write a wrapper function, this will either just call println or if you are in a debug build call LogError instead.
    Next put the function name in calls to said wrapper, eg
    MyPrint("LoadImages: File " + filename + "Was missing");

    For [2], don't use large scope exception handlers, that handle the errors of say 10 different record method calls.
    Have one exception handler each, now, if you end up in said exception handler you know which bit of code has caused you to jump here.
    Ok granted, you won't know the whole call stack, but its an improvement. Again you can use LogError in your exception handler, and you will get to see most of what went wrong.

    If you really want a call stack, write your own. Its what I did. You will need to insert a piece of code into the beginning and end of each function, I recommend only doing this to functions of interest to keep the extra code/coding to a minimum.

    You could either base said call stack on string names (i.e. the function names), or just use numerical labels. Also don't try and trace any functions that run on multiple threads, I know from experience this only leads to a heap of confusion

    Lastly, to avoid getting [3], test for errors from standard library calls, and then use LogError if you get any, thus making sure you get to see the error on a real phone.

    I good tip, for doing all this, and not adding several meg to your jar, is to use a preprocessor on your code.
    I personally use the C preprocessor (cpp), this allows me to do stack tracing, debug printing, etc all at no overhead, because I can just undefine #define ALLOW_PRINT, and all of the above code vanishes from my java files.

    It occures to me, that writing a custom java VM for the phone, is probably the easist way to get access to the stdout and stderr streams, god knows how you would do that.

    Hope this helps abit.
    Alex

  8. #8
    Registered User
    Join Date
    Jan 2004
    Location
    Poland
    Posts
    49
    Thanks guys for your thorough replies.
    So I can workaround it partially.

    As to the other part of my question - have you seen any more complex document with description of the phone - emulator runtime differences? Or id that any info about it is scattered somewhere?

    Another thing - do you know a good network monitoring tool that could monitor any emulators' networking just like WTK's network monitor?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •