Exception Handling - Textures and Sounds

[divzero]

Currently with the texture and sound loaders most of the exceptions are unchecked. In other words if you are missing a texture the application bombs out unless you explicitly check for them.

I propose that we change to the standard practice of using checked exceptions to force the developer to check for exceptions which can reasonably be thrown (ie. image not found).

This may cause some people strife as it is a change to the API and they will have to add try catch blocks in some places - but hey we’re not at version 1 yet and the sooner the better as far as this is concerned.

I am more than happy to put the work in and modify Xith3D - but it first needs approval.

I believe that such “missing media” exceptions are ones that the programmer should be forced to catch as there is a good chance they will crop up and hence we should use checked exceptions instead.

Regards,

Will.

PS. Please post your opinion along with your yey or nay votes

[kevglass]

+1

I was suprised to see it wasn’t already done (albeit relieved for quick devs )

Kev

[endolf]

+1

I was surprised too, I tend to go the other way though, and throw every exception I can including making up a few of my own

Endolf

[abies]

I’m against checked exceptions for this case. Texture is just a resource, and if it is missing, this means program is written or deployed in wrong manner. If you load it from local filesystem, it will work unless some kind of internal error happens - and in this case, application is not able to recover anyway IMHO.

What do you plan to do if textures for your objects are missing ? Fall back to default ones ? Display them untextured ? I would rather prefer to not be forced to write exception handlers everywhere for nothing. If somebody really wants to write fallback, he is free to do it with unchecked exceptions.

Situation is different for files loaded on request of user for example. It is clear that some errors can happen here and they can and should be handled, displaying correct message and allowing user to try again. But if it is deep inside program, I do not think that checked exception is a way to go. For me, requiring to check for availability of texture in generic case is the same as requiring every reference to outside class to catch exception in case this class was deleted from jar after compilation.

Of course, you have different case, if you for example allow user to specific per-model textures in config file. But then, IMHO, checks should be done explicitly during config file parse, not by 3d engine at time of model loading (possibly in middle of level load).

[kevglass]

I assume this is just a difference of opinion here, and I’m not trying to offend anyone, but couldn’t you say that about any exception. If the developer wants to catch it then they can, but that of course assumes they know about. One of the nicest differences from moving C++ -> Java for me was the amount of intelligent checking the compiler gets to do.

In counter to the “but what are you going to do about it argument?” well I’m going to handle it gracefully and not let it just let it fall out and if possible I’d like the compiler to point it out if I forget.

Again tho, its probably just an opinion based thing, so I suppose the vote is the best idea

Kev

[Preston]

+1

I vote for following the Java philosophy of forcing the programmer to catch exceptions in all sensible places.
If you do a resource loading via “new FileInputStream(…)” (or such) you have to add a try-catch block (or “throw exception” behind the method), otherwise the compiler reports an error.
That’s robust and clean.

Actually I love that. As a former C++ developer I know we’ve “forgotten” (lazyness, dead lines, etc.) many times to do correct error handling throughout the application. Java takes care of this in most cases at compile time, not at run-time.

I’d feel very comfortable if Xith3d did the same. So when you have to try-catch a new FileInputStream I think it’s sensible to have to try-catch the Xith3d’s texture loader, for example, too.

[divzero]

Personally I like the compiler telling me what exceptions have a good chance of being raised and giving me the chance to deal with them so I am definitely with Kev on that one.

What disadvantages (apart from a few extra try catch blocks) are there in using checked exceptions? I think it’s better that people be forced to choose to ignore exceptions than be forced to pay close attention to the source and docs and be on the lookout for exceptions they should catch or prevent from happening. And if we are talking about more code - then testing to prevent every possible exception is far more lines of code than a simple try catch!

I agree that RuntimeExceptions have their use - but in the case of IO operations I feel checked exceptions are more appropriate Using checked exceptions for IO operations would also bring us inline with the Java API as a whole and this I believe is what people new to Xith3D will expect as that is what they are used to.

Cheers,

Will.

[abies]

As long as you see a texture load as I/O operation, then I agree. But why do you not expect checked exception on implicit class load ? It is loaded also loaded by I/O after all.

For me, texture is same kind of resource as class file. I do not write try/catch blocks when loading new class by referencing it and I do not want to write try/catch block to access other granted resources.

For me, checked exceptions are for things you cannot trust and unchecked are for things you can expect to work well, unless some kind of unrecoverable error happens (be it programmer error, jvm setup, program setup, etc). I think that most people will agree here. Difference between us is that I consider textures as guaranteed resource, same as any of class files of program. You look at it as transient, unsure thing, which can dissappear at any moment.

We both agree that exception should be thrown. As far as checked versus unchecked is concerned, there is no real way to just say ‘this is right’. Best examples are java core - NumberFormatException should be checked for sure, while I would personally rather not force people to check for CloneableNotSupportedException.

Please only tell me, what will you put inside catch blocks for cases where texture which you have bundled with application is not there ? It cannot happen in normal case, but catch block has to be written. I have too many times seen rethrow as unchecked exception…

[kevglass]

In the past I’ve had a catch that displays a dialog explaining to the end user that the install appears to be corrupt and suggesting possible fixed, i.e. try a reinstall or contact the developer at blah @ blah.com

Arguably this could be done generically from a catch throwable around every thread so if anything goes wrong the same message is wrong.

Which ever way it turns out either one of us could write a wrapper class to do the opposite anyway… not to mention that I assume that no-one uses the texture loader quite that directly from lots of places in their code… more like some sort of central resource manager class… which could just catch and rethrow (either solution).

I just fear for adding the extra time discovering that there is an exception to catch. One seems to be passive, i.e. “wait til something goes wrong then the developer will fix” and the other non-passive i.e. “force the developer to code for the exception now and never think about it again”.

As I said I’m starting to think I don’t give a rat’s arse about this either way

Kev

[della]

This article has been recently pointed out at java.net:
http://www.onjava.com/pub/a/onjava/2003/11/19/exceptions.html

The key point is:

---

1. When deciding on checked exceptions vs. unchecked exceptions, ask yourself, “What action can the client code take when the exception occurs?”

If the client can take some alternate action to recover from the exception, make it a checked exception. If the client cannot do anything useful, then make the exception unchecked. By useful, I mean taking steps to recover from the exception and not just logging the exception.

I agree with this vision, that is the same abies has.

[divzero]

[quote]As long as you see a texture load as I/O operation, then I agree. But why do you not expect checked exception on implicit class load ? It is loaded also loaded by I/O after all.

For me, texture is same kind of resource as class file. I do not write try/catch blocks when loading new class by referencing it and I do not want to write try/catch block to access other granted resources.
[/quote]
In a way I agree but I think this is looking only at the specific use case where all texutres will be bundled. Who says one has to use the TextureLoader class with Xith3D? I look at it as a generic fast image loading library, which it really is.

If a model loader is being used, the loader can simply catch the exceptions for you and bundle them as a RuntimeException if that is what you prefer.

For me, checked exceptions are for things you cannot trust and unchecked are for things you can expect to work well, unless some kind of unrecoverable error happens (be it programmer error, jvm setup, program setup, etc). I think that most people will agree here. Difference between us is that I consider textures as guaranteed resource, same as any of class files of program. You look at it as transient, unsure thing, which can dissappear at any moment.

We both agree that exception should be thrown. As far as checked versus unchecked is concerned, there is no real way to just say ‘this is right’. Best examples are java core - NumberFormatException should be checked for sure, while I would personally rather not force people to check for CloneableNotSupportedException.

Please only tell me, what will you put inside catch blocks for cases where texture which you have bundled with application is not there ? It cannot happen in normal case, but catch block has to be written. I have too many times seen rethrow as unchecked exception…

I would probably log the exception and move on - others may rethrow it thus killing the application.

While a missing texture is bad - it’s not the end of the world. I dont’ want my game to fail just because I forgot to package the texture for a single blade of grass (and forgot to catch the RuntimeException).

Using checked exceptions forces the programmer to choose if they want to handle them or not. I think that is better than leaving them to their fate.

Having unchecked exceptions everywhere also makes the application more crash prone IMHO. There are many exceptions which the application really should recover from and move on and checked exceptions would make people more aware of them.

Cheers,

Will.

[divzero]

Some supporting articles which I agree with:

http://www.javaworld.com/javaworld/javaqa/2002-02/01-qa-0208-exceptional.html (section: “The Logic” half way down page)

…

Catching runtime exceptions also leads to a worse problem: what exceptions do you catch, and when do you catch them? Runtime exceptions are undeclared, so how do you know what you should catch? How do you know there’s an exception to catch? Certainly you wouldn’t place try/catch blocks around every method call and array access you perform?

and http://www.oreillynet.com/cs/user/view/cs_msg/18557

You should use exception handling to indicate errors.

RuntimeExceptions indicate errors in your program logic that you should fix (things like NullPointerExceptions). RuntimeExceptions are things that should NEVER happen in properly debugged code.

Checked exceptions, things like FileNotFoundException are things that can reasonably happen in code AND you cannot defend against in your code (like you can a NullPointer). Checked exceptions do not indicate logic errors in your code.

If the compiler did not force you to deal with checked exceptions then you would have to know what each method throws. To do this you would presumably need to check the documentation.

If you are going to write “proper” robust code you are going to want to handle all errors (right?). WOuld you rather have the compiler help you out or would you rahter do things manually?

One way or antoerh you should be handling all the errors - why not let the compiler help?

Why I agree is I think that missing media is not bug in the code but rather a problem with the distribution be it human error, failure of the distribution media or some other factor and doesn’t affect code logic.

Will.

[joo]

My vote is +1 for using checked exceptions when loading resources.

I think it all boils down to the question “What action can the client code take when the exception occurs?”. Usually an application has central utilities for loading sound, models and images. Even if we assume the media has to be there, this enables us to exit the application gracefully and it doesn’t blow the code up. Usually the resources are on the local harddisk, but there may be cases when you load resources over the network or on the request of a user. In these cases you must be able to handle exceptions. The third argument is that the Java core handles IOExceptions as checked ones.

[divzero]

it would be nice to have a resolution on this issue (checked vs unchecked).

So far we have:
4 +1’s and
2 -1’s

Even if we decide not to force checked exceptions - then we should create a bunch that extend RuntimeException so that at least dev’s that want to catch them nicely can (and get rid of all Error classes being thrown).

I am happy to implement whatever we decide.

To reiterate:

I am proposing that we create several Xith3d Exceptions including some checked and unchecked ones. I am suggesting that I/O operations such as loading texutres and sounds should have checked exceptions and everything else unchecked ones. This would upgrade the current exception system which is simply throwing “Error”.

Will.