1. Re: crash_message
> To David & Ralf: I suppose the simplicity, clarity, and power
> of Euphoria is enough to attract people to it. But I still
> think what makes it stand out even more than that is it's
> rigid, prohibitive design and double-checking, interpretive
> implementation. Again, I'm not saying we don't need some way
> to take care of errors in Euphoria, I'm just trying to stress
> the need to explore all possibilities before opting for a
> quasi-Euphorian mechanism like crash_routine (just like I'm
> sure other possibilities were explored before the adoption of
> routine_id.)
Double-checking, rigid, prohibitive design -----> Safety
It helps create programs that don't crash: it makes them rock-solid.
Precizely how, is a crash-routine _not_ inline with this ideas ?
BTW, Precizely how could such a mechanism be abused anyway ?
There are three options:
1) The program was aware of the risk, and uses the error handling to
continue the program with option X2234
2) The program wasn't expecting a crash, and will not try to store the data
and close down the program.
3) The program wasn't expecting a crash, but the crash happened in a client
part (for example, within a Bot in my BotMatch), the server continues and
removes the error-prone bot from the play-list.
I don't see any abuse ? When would it be abuse ? Only, when you're using it
to *fix* your program, without knowing what caused the error. But fixes can
be ugly in a million more ways.
Ralf N.
