This project is read-only.

Error System

Dec 7, 2007 at 11:33 AM
Do we have a consistent way of announcing errors? How about the engine has a special message type for erros, and when the gui recieves this message, it shows a standard dialog with the error text.
Dec 7, 2007 at 11:44 AM
We could also simply consider using Console.Write and then just redirect the output to the relevant target (Console could be one). Fatal exceptions (connection lost etc) are a different story as we will need another system to handle this. It might be a system message which each sub system reacts on.
Dec 7, 2007 at 3:36 PM
Wouldn't throwing exceptions be fine for fatal errors? Or do we want something less brutal?

As far as announcing errors, I think the user should have a choice of the level of notification. On the template v0.182 I had any messages you wanted to send go to a log file, which is fine if the user doesn't want to break on errors, and is fine with seeing them AFTER the program has ended. However, for runtime notification I would just send messages to the console (which would also end up in the log file if you wanted). Having a separate console window like Sturm suggested isn't a bad idea either, although it can be difficult with single monitor systems when running in fullscreen.

In the end I think we should have at least 3 levels of error notification:
1.) Throw an exception
2.) Send notification to a file
3.) Send notification to a console window/or to a HUD console.
Dec 7, 2007 at 3:56 PM
Cheers. The error I was thinking off is serious, so Ill through an exception for it. I just wondered if we had a way of doing it.
Dec 7, 2007 at 5:43 PM
Exceptions are alright for unrecoverable errors, but you have to be careful. If you enclose a method call in a try/catch block, that's good for catching probable errors but don't do it hundreds of times a frame! There is overhead in just entering a try block, regardless of whether or not an exception is thrown or if there's even a catch block (think try/finally). And if an exception is actually thrown, all the logic there can easily be fatal for per-frame processing. Moral of the story: I wouldn't use exceptions as an error-checking scheme for operations that have a decent probability of failing and you can continue execution if it fails. i.e., don't do this:

    Dictionary<int, int> myDictionary = new Dictionary<int, int>();
        int i = myDictionary[4];
        // Process key 4
        // dictionary must not contain key 4, do something else...

As for fatal, program-cannot-continue-even-one-more-statement errors, propagate a global exception. The entire game.Run() statement will be in a try/catch block, and the exception handler will be coded to provide nice, well-formatted information to the user instead of a simple "This program has performaned an illegal operation and must be terminated." window. Even on Xbox, we can probably get away with flushing the entire graphics system and putting up some text on the screen describing the exception.
Dec 7, 2007 at 6:27 PM
Exceptions should never be used as error handling, shaw is absolutely right. As the word implies we are now in a unresolved state, we have no way of knowing how to recover (Though you might be able to know that in a very limited area).

As for the example above, it really shows the absolute incorrect way of using exceptions. First the penalty of entering the try then (lets assume there are only 3 elements) throwing an unneed throw and at last the system must traverse and build the exception. A much nicer way of doing it:
    Dictionary<int, int> md = new Dixtionary<int, int>();
    if (md.ContainsKey(4) == false)

Also catching Exception or not specifying any type of exception to catch is just wrong on so many levels. You have to be specific.
Dec 7, 2007 at 6:37 PM
Hehe, I'm glad I was able to make you cringe. :)