At 6:18 PM +0200 on 6/5/99, M. Uli Kusterer wrote:
>I know GetErrorMessage() appears to be a stupid implementation when you
>consider localization, but I intend to have it call a standardized
>string-fetching routine which will fix the localizing problem.
Hmm... char *, loaded from disk in an implementation-defined fashion...
into memory... (anyone see a leak here?)
How about a "string" instead of a char *?
>The default
>implementation of GetErrorMessage() would fetch the appropriate situation
>and error strings based on mSituation and mErrorCode and then concatenate
>them to generate an error message.
Concatenation would certainly be fun across multiple languages. Imagine,
SITUATION: "While on line x of script of background button blah
blah blah in the tokenize and compile phase, [we'd
need better words for these]"
ERROR: "an unexpected token error occured."
Would that translate and concatenate right into French? German? Japanese?
>For more complex errors, we creplace
>placeholders in an overridden GetErrorMessage() to fill in additional
>information (like the handler we failed in or the amount of memory we'd
>have needed).
Basically, ParamText()?
>- A standardized way to get at the error message. The specifics are only
>known to the class and the one who throws the exception, which allows to
>keep the code much more generic. No need to "if" etc. when displaying
>errors.
True. That's certainly a plus.
>
>- It's a class, not a struct, which is more C++-like
A class is a private-by-default struct. Sheesh!
>
> BTW, Anthony, I'm not sure whether we should use the ": mSituation(sit)"
>syntax in our classes (you seem to do this a lot), as I'm not sure every
>compiler supports this,
I'd think that every C++ compiler does; it's been there for quite some
time. And it's the only way to initialize classes (within the class) inside
a constructor.
Besides, the STL uses it a LOT and so do most pieces of code I've seen. And
before even worrying about support for that, worry about exception,
template, and namespace support!
>and it's also less clear whether it's a variable
>being set or a function being called.
It is a function being called. (You didn't expect me to say that now, did
you?) It's a constructor call.
