GAGETimer and the error trace

Shared Code
#1

Hmmm.

I remember a brief discussion about this in a thread IIRC about puppytron. If GAGETimer can’t find the timer.dll it prints an exception and continues. Originally i thought that puppytron was catching the exception and printing the trace. Just replaced the Java3D timer with GAGEtimer though and i notice that GAGETimer ITSELF actually prints the stack trace out to System.out

Would it not be better to catch the error and then re-throw an exception or something ? Obviously you don’t want an error propogating up through the stack because that would kill the app if the DLL wasn’t there. However catching it and throwing another exception would fulfill most of what JBanes was talking about originally when he explained his reasoning behind having it print out…

I’m not actually having any trouble with it at all (good stuff incidentally) and i’ve recompiled the thing without the stacktrace printout myself, I just think it’d be … Nicer … if it worked like the above :slight_smile:

So i’m now finally completely free of Java3D. Hurrah ! unfortunately 5 seconds after deleting all the Java3D jars and libs i discovered that i’d lazily been copying and pasting all my imports all the way through my project. So 10 minutes later AFTER going through my entire codebase and laboriously checking everything out , killing the Java3D imports and checking everything back IN again THEN i was finally able to recompile. Theres a moral there somewhere :slight_smile:

D.

#2

Why would you want it to throw an exception? GAGETimer is just working a little bit of magic. If it finds the DLL, it uses it. If it doesn’t find it, then it falls back to the system timer. The only purpose of the stack trace is to make developers pay attention. If the DLL isn’t loading when it should be, they’ll ask for help with an error in hand. If I simply printed a message “DLL not found”, most programmers would say “It isn’t working right, but there are no error messages!” Sad, but true. :-/

#3

I think its just the semantics of GAGEtimer ITSELF actually writing out to System.out that seems a bit whiffy. I know it works fine with or without the DLL so having an UnsatisfiedLinkError pop up on System.out looks as though something terminal has happened. Throwing an exception on the other hand would allow the user of the library to decide what they want to do with it. As i said its no big deal because anybody who wants to can recompile it anyway. Anyhoo, I don’t want to carp*, I’m heartily appreciative of it :slight_smile:

D.

*even if it is a bit fishy. hohohoho.

#4

[quote]I think its just the semantics of GAGEtimer ITSELF actually writing out to System.out that seems a bit whiffy.
[/quote]
Understandable. More correct behavior would be to simply print a one line message stating that the timer is falling back. The problem is that I don’t trust 90% of the people who use the technology. I’ve seen far too many newbies run off and try to “do things differently” because they think they know better. At least the error forces them to stop and think. :slight_smile:

[quote]I know it works fine with or without the DLL so having an UnsatisfiedLinkError pop up on System.out looks as though something terminal has happened.
[/quote]
Since GAGE is primarily useful in environments where the DLL would be available, making programmers think that “something has happened” is kind of the point. It can potentially save them days of debugging, and save me quite a few support headaches. :slight_smile:

[quote]Throwing an exception on the other hand would allow the user of the library to decide what they want to do with it.
[/quote]
There’s certainly some merit to such a design. However, a timer is probably far too simple a device to be adding such complexity to the user’s program. Not to mention that the timer would need to be re-architected to allow for the exception to even reach the user. :slight_smile:

[quote]As i said its no big deal because anybody who wants to can recompile it anyway.
[/quote]
Heh. Do I have some war stories on THAT one. “I changed the package name to com.bob.timer, and now the DLL doesn’t load! Why doesn’t this $#%@ work?!” ;D

[quote]Anyhoo, I don’t want to carp*, I’m heartily appreciative of it :slight_smile:

even if it is a b*it fishy. hohohoho.
[/quote]
groan

#5

I’d also prefer it to not print out. Perhaps you could explicitly call:
Timer.DEBUG = false;
or something of that nature to turn it off. Honestly I get complaints from users either wondering what’s wrong with the game or telling me that it’s broken and they think they’re helping me by sending me that.

The way I’d most like to see it is for the GAGETimer to not throw any exception or print anything out. I think it should just work. However, I think you should have a method like, getTimerDescription() which would return the same text printed out now. That way programmers could choose to display this information if they find it useful.

Right now it seems that the only way to have your game look professional and to use GAGETimer is to recompile it with that changed. Even the “Using 1.5 NanoTimer” or whatever it says I’ve gotten enough harps about to be annoyed.

So yeah, I compile it myself now, too. However I’d think in your position you should hear about these results because I believe those changes will make your library look more professional.