Re: [Alephmodular-devel] On errors

[Dietrich E. <die...@zd...>]

On Friday, January 31, 2003, at 07:23 , Br'fin wrote:

> In general, I like the design I put forth for IFailable. It's intent 
> was not to cover an object handled by several threads at once.



> The area I'm having problem is with with CError objects. As I work on 
> it, I'm going lets add this and lets add that. And consequently it 
> seems to be lacking a proper elegance to it.
>
>
> Marathon handles errors like so:
>
> The game hits an error and calls set_game_error(type, code)
>
> Type may be a gameError or a systemError. If it's a gameError, than 
> code is limited to a particular subset of codes. If it's a systemError, 
> than the particular error is recorded in the code.
>
> Code higher up the hierarchy can check if the game has an 
> error_pending, it can read what kind of error is around with get_error 
> and can clear the error.
>
>
> For instance, file finding code might report (systemError, 
> fileNotFound) Further up the code sees this and says: Error pending? 
> Ok, what is it? File not found? Ok, it's just the preferences, clear 
> the error and continue on to create the file.
>
>
> For a contrasting viewpoint on errors, I looked at Java. That has the 
> hierarchy of 'Throwable' leading to 'Exception' (things which your 
> program should catch) and 'Error' (Things which your program shouldn't 
> catch, they're just too big). And then further breakdowns of errors.
>
> In our case this would work out to one SystemException and then 
> GameException with a hierarchy of specific exceptions beneath it.

Maybe... then maybe the exact circumstances under which an exception is 
thrown should be better defined first.

<thinking-out-loud>
Runtime exceptions happen in I/O, system calls, and other juicy things 
like buffer overflows.
Logic errors happen anywhere you shouldn't pass a nil pointer, or 
something is out of range, etc.
</thinking-out-loud>

It seems that runtime exceptions should be caught, interpreted, and 
presented to the user in a friendly manner such as "The shapes file is 
corrupted." or "The network connection vanished.", whereas logic errors 
should present themselves as bug reports - "Range error thrown at 
foo.cpp:273, caught at bar.cpp:450.  Please report this to 
<bug...@bl...>."  Logic errors could also be marked as 
irrecoverable, so after the bug report is presented the game quits.

> Another thing about Java exceptions is that the interface is fairly 
> simple, You create a new exception and the string argument in the 
> creator is optional.
>
>
> Hsm, was just thinking about exceptions and C++. Exceptions get to be a 
> nuisance if the current function itself is just a pass through for an 
> exception. (open_preferences would continue to throw a 
> fileNotFoundException that originated in open_file and also had to 
> propagate through wad_open.) Or do you just need to pussyfoot around 
> your declarations to make sure that if you're passing an exception that 
> you didn't declare any memory before the point where the exception can 
> occur?

It's not really that weird, just C++ isn't garbage-collected like Java 
is.  You can deallocate in a catch block or by using destructors.  The 
auto_ptr's will free their pointees automagically.


On Thursday, January 30, 2003, at 04:39 , Br'fin wrote:

> My first instinct is 'what on earth do we have for objects that are 
> accessed in multiple threads *AND* which are failable'.
>
> As for existing error handling, I was looking at game_errors.h/.cpp and 
> some of how iostream type stuff does it. In the case of an iostream, 
> the stream itself does get into bad states (The object is affected)

Well, yah.  File handles have states, so there is no possible situation 
in which error is independent of state.  But other objects aren't like 
that, and multiple error-handling systems would be ugly.

> A quick perusal of set_game_error (Current error handling) reveals the 
> majority are around file handling (basic, wad, and preferences) and a 
> couple netgame spots. (Inability to sync with others or server died)
>
> In the case of Marathon, the game itself goes into a bad state until 
> falling far enough back in its main thread to correct it and/or report 
> to the user.

This would be a heck of a lot cleaner without explicit error checking, 
as exceptions provide.

I think I'd enjoy these concepts a whole lot more if I didn't absolutely 
hate C++.