I just modified a little your TestWidgetButtonLightSwitch to add “click” sound while pressing the buttons, Hope you don’t mind…
Very cool! Got everything working together in that test
That does lead me to another topic though… not to thread jack. Currently, if there is a texture or sound missing and the texture manager tries to load it or the sound manager tries to load it, an exception is thrown and the app dumps. I noticed this, because I forgot to update the data directory and didn’t have the click sound. Is dumping with when bad data is requested the preferred method or should the load just fail and that texture/sound won’t be in the app? I lean towards keeping the app running just without the missing resource.
Do you mean that we should force exception throwing or write more secured code by checking all errors for tests?
Well, that’s the question I was asking. I am leaning towards catching and handling exceptions related to bad resources. But others may feel that if a user tries to load something that isn’t there the application should shut down and display an exception (which is what it does now).
BTW after updating to get the sound click. I’m getting errors in the sound package. EffectRepository cannot be resolved, filter cannot be resolved, IBufferFilter cannot be resolved, etc, etc.
My opinion is that the ressources are part of the application… so if the user deletes a file for example his players model you can’t let the application continue.
In an other way it is true that we can add more exceptions and display a message to say that a ressource is missing…
Well as ,actually, I dont give an opinion, we can vote for it.
package problems are resolved now
I’ll side with mojomonk on this one. If a load fails, the app should continue as normal, just running without that resource. There should still be some way for the user to determine if the resource was successfully loaded, however.
A more complicated mechanism, but potentially more powerful, is a user setting to either die or continue on a failed resource load. Perhaps something like JmeCore.setLoadFailureAction(CONTINUE_ON_FAILURE)?
Oh yeah, and the test is really cool.
I’ll throw my 2 cents worth in here.
I think the decision to halt execution of an application should be at the application level.
I’m of the opinion, the underlying api, if possible, should pass the exception up to be handled by application.
If the application wants to tell the user they’re missing something it can, then it can exit, keep running, call 911, or whatever.
The api can log the exception so we can figure out where the problem is occurring if we need to.