Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (109)
games submitted by our members
Games in WIP (537)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Exception Handling - Textures and Sounds  (Read 1627 times)
0 Members and 1 Guest are viewing this topic.
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Posted 2003-12-17 03:44:27 »

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 Smiley

Offline kevglass

JGO Kernel


Medals: 123
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #1 - Posted 2003-12-17 06:10:49 »

+1

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

Kev

Offline endolf

JGO Coder


Medals: 7


Current project release date: sometime in 3003


« Reply #2 - Posted 2003-12-17 06:20:05 »

+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 Smiley

Endolf

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline abies

Senior Member





« Reply #3 - Posted 2003-12-17 09:57:50 »

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).


Artur Biesiadowski
Offline kevglass

JGO Kernel


Medals: 123
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #4 - Posted 2003-12-17 10:18:35 »

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 Smiley

Kev

Offline Preston

Senior Member


Medals: 4



« Reply #5 - Posted 2003-12-17 11:24:32 »

+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. :-)
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #6 - Posted 2003-12-17 11:37:05 »

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.

Offline abies

Senior Member





« Reply #7 - Posted 2003-12-17 12:07:57 »

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...

Artur Biesiadowski
Offline kevglass

JGO Kernel


Medals: 123
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #8 - Posted 2003-12-17 12:19:01 »

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 Smiley

Kev

Offline della

Junior Newbie




Java games rock!


« Reply #9 - Posted 2003-12-17 14:13:39 »

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.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #10 - Posted 2003-12-17 21:28:19 »

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.


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.

Quote


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.

Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #11 - Posted 2003-12-17 21:34:59 »

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)

Quote

...

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

Quote

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.

Offline Jens

Senior Member




Java for games!


« Reply #12 - Posted 2003-12-18 13:23:18 »

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.

Xith3D Getting Started Guide (PDF,HTML,Source)
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #13 - Posted 2004-02-25 02:29:57 »

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.

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

CogWheelz (16 views)
2014-08-01 22:53:16

CogWheelz (15 views)
2014-08-01 22:51:43

CopyableCougar4 (18 views)
2014-08-01 19:37:19

CogWheelz (19 views)
2014-07-30 21:08:39

Riven (27 views)
2014-07-29 18:09:19

Riven (16 views)
2014-07-29 18:08:52

Dwinin (14 views)
2014-07-29 10:59:34

E.R. Fleming (42 views)
2014-07-29 03:07:13

E.R. Fleming (13 views)
2014-07-29 03:06:25

pw (44 views)
2014-07-24 01:59:36
Resources for WIP games
by CogWheelz
2014-08-01 18:20:17

Resources for WIP games
by CogWheelz
2014-08-01 18:19:50

List of Learning Resources
by SilverTiger
2014-07-31 18:29:50

List of Learning Resources
by SilverTiger
2014-07-31 18:26:06

List of Learning Resources
by SilverTiger
2014-07-31 13:54:12

HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!