Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (120)
games submitted by our members
Games in WIP (577)
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  
  Exceptions slow?  (Read 1558 times)
0 Members and 1 Guest are viewing this topic.
Offline Sanxion

Junior Duke




Java games rock!


« Posted 2003-12-27 09:20:16 »

What are the caveats of using Exceptions? I heard they were slow and should be avoided. What are the alternatives? Judiciously check all data with if/else statements?
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #1 - Posted 2003-12-27 09:36:54 »

I never experienced that Exceptions were a performance bottleneck. I think when an exception is thrown, you just need to be aware that some objects are created so you might get a bit of garbage when your code throws a lot of exceptions in inner loops or something.

As always, I'd say just design it the proper way. Which is using exceptions where applicable and *if* it turns out to be a performance bottleneck after profiling, do something about it then.

Erik

Offline abies

Senior Duke





« Reply #2 - Posted 2003-12-27 10:08:51 »

Exceptions are slow - if they are thrown. In addition to object creation (which is non issue), you need to create copy of entire call stack, unwinding frames - this is sometimes non-trivial, especially in presence of inlined methods.

I don't think that anybody actually suggests avoiding exceptions totally. But, given error-free execution of program, you should not rely on exceptions as a method of controlling program flow. Best example is opening a file - you expect it to be there and in normal case, everything goes without exception. If it is suddenly missing or non-readable, you can throw exception - user will be probably alerted and asked for action anyway, so any millisecond-wide costs are not noticeable.

Do not use ArrayIndexOutOfBounds to terminate loops. Do not use NullPointerException to manage non-initialized element of some map if it is bound to happen often. Etc, etc.

BTW, as far as costs are concerned, one of the MAJOR areas where Exception cost is visible is class loading. If you have a number of classloaders, with classes distributed between them, there is no easy way to check if class if defined there - you need to ask for it and catch exception if it is missing. This was a major problem with Netbeans - they had many jars with classes, and tens of thousands exceptions thrown during application startup, because class was looked for in wrong jar at start. AFAIK, after performing some optimalization (providing info which class should be looked for in what jar) they had reduced startup time from 25 to 20 seconds or something like this.

As for Erik suggestion of profiling first, please note the "using exceptions where applicable" part. If you will design your control flow to be exception driven, changing it will be very hard later. IMHO, it is a thing which should be done right from very start.

My rule of thumb is quite easy - use exceptions for exceptional situation. If all variables outside scope of application (filesystem, network, memory, user input etc) are correct, no exception should be thrown. Of course, it is sometimes not possible, but for me it is a goal which helps me to decide when use exception and when do it 'manually'.

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

JGO Kernel


Medals: 407
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #3 - Posted 2003-12-27 10:56:03 »

An even easier way to summarise that: never rely on exceptions for your code to work properly.

Cas Smiley

Offline Sanxion

Junior Duke




Java games rock!


« Reply #4 - Posted 2003-12-27 17:32:34 »

An alternative would be to return a ResultObject. The exceptions could have static ResultObject(s) thus no new classes would have to be created in comparison to thrown.
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #5 - Posted 2003-12-27 23:02:27 »

Quote
My rule of thumb is quite easy - use exceptions for exceptional situation. If all variables outside scope of application (filesystem, network, memory, user input etc) are correct, no exception should be thrown. Of course, it is sometimes not possible, but for me it is a goal which helps me to decide when use exception and when do it 'manually'.


Basically that's exactly what I meant by 'where applicable', I was just a bit vague Smiley
The cases where I use exceptions are the cases where it won't matter much if an exception is costly or not, 'cos those are the cases where we're screwed anyway Smiley
In the really performance critical parts, I don't even want to be checking data if possible in order to see what kind of ResultObject I'd want to return at all.
So, for example in Cosmic Trip exceptions might be thrown at start up, shut down, sending a high score to the server, fetching the high scores from the server or handling a complete crash for cases I didn't see coming (so that the game shuts down when something occurs I didn't see coming).
But, if you really demand more exceptions to be handled in your performance critical part (the running game I imagine), something like ResultObject you described might be cheaper than exceptions *if an exception would be thrown*.
OTOH I can imagine checking your data constantly to return a proper ResultObject every time could even cost you more in the case an Exception would *not* be thrown, which is what 'normally' would be the case.

Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #6 - Posted 2003-12-27 23:11:56 »

Quote
Do not use ArrayIndexOutOfBounds to terminate loops.


Actually when I think of it, I did exactly that in early version of the CottAGE emulator in a part that took >50% execution time (an inner loop somewhere in the rendering). It was kind of a dirty workaround of a bug in the clipping code.  The strange thing is, it didn't make much of a difference (not noticable) when I fixed the bug and removed the try and catch and the ArrayIndexOutOfBounds used to happen quite a lot... Hmmm...  :-/

Offline Jeff

JGO Coder




Got any cats?


« Reply #7 - Posted 2003-12-28 00:07:58 »

Throwing an exception isn't bad, however creating an exception TO throw can be slow, mostly because it has to extract and create a representation of a stack trace.

HOWEVER it is a given that you should NEVER NEVER use exceptions for control flow.  Its just bad coding and leads to less maintainable code.  Exceptions are for exceptional conditions, those conditions you expect to encounter extremely rarely, if ever.

If there IS a reasonable return value from a call it should return it, not throw an exception.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Sanxion

Junior Duke




Java games rock!


« Reply #8 - Posted 2003-12-29 04:05:24 »

I was thinking of something like this. Any input in contrast to exceptions?

With the below I can do the following:

ResultObject resultobject = doSomething();
if(resultobject.getResult()==null){
      System.out.println(resultobject.getError());
}

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
public class ResultObject{
      private MyObject result=null;
      public MyObject getResult(){
            return result;
      }

      private static int final ERROR_NONE = -1;
      private static int final ERROR_TYPE_MISMATCH = 0;
      private static int final ERROR_TOO_LARGE = 1;
      private int error=-1;
      public int getError(){
            return error;
      }            
}
Offline princec

JGO Kernel


Medals: 407
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #9 - Posted 2003-12-29 08:28:10 »

You'd only really want to use that particular pattern if an "error result" was not an expected result.

Cas Smiley

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.

Longarmx (52 views)
2014-10-17 03:59:02

Norakomi (44 views)
2014-10-16 15:22:06

Norakomi (34 views)
2014-10-16 15:20:20

lcass (38 views)
2014-10-15 16:18:58

TehJavaDev (68 views)
2014-10-14 00:39:48

TehJavaDev (68 views)
2014-10-14 00:35:47

TehJavaDev (60 views)
2014-10-14 00:32:37

BurntPizza (73 views)
2014-10-11 23:24:42

BurntPizza (45 views)
2014-10-11 23:10:45

BurntPizza (87 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

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

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

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
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!