Re: [Alephmodular-devel] Random rumblings on files and errors

[Br'fin <br...@ma...>]

On Thursday, January 30, 2003, at 07:02  PM, Dietrich Epp wrote:

>
> On Thursday, January 30, 2003, at 03:37 , Br'fin wrote:
>
>> Er, is which element hopelessly unthreadable?
>>
>> The current error handling.
>> This error handling.
>> Or?
>>
>> And I'd not mind knowing why. (I didn't think to take that 
>> possibility into account, so...)
>>
>> -Jeremy Parsons
>
> The bit about each object holding an error value.  If two threads use 
> the same object, the error value won't work correctly.  It also seems 
> that error data are not the property of an object itself, rather the 
> property of an aborted call, which is what exceptions are for.

Hmm, unknown. I honestly hadn't been thinking of threads.

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)

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.

Admittedly, you do have a better argument for 'why exceptions'

-Jeremy Parsons