Larry Wall wrote:

On Wed, Aug 11, 2004 at 04:16:48PM -0400, Dan Sugalski wrote:
: If it's that handy then someone can write a library routine. This : feels very much to be in the same category as running a : speech-to-text algorithm if you send WAV data to a text filehandle.


Well, you can write a library routine, but if you have to invoke it
in a separate pass it's not as efficient.

: Not going to happen. Charset conversion mismatches either throw an : exception or falls back to a default bogus character.

Seems to me that a reasonable compromise is merely to provide a way
to hook in a user-defined callback and leave it at that.  Then the
user can have whatever policy they like, and Dan doesn't have to
implement it.

Larry
From - Fri


It strikes me that many of the same issues that I just raised (or tried to raise, anyway) to try to clarify what I was saying to Brent apply equally well here, to the suggestion of user-defined callbacks. Specifically, what happens if you want to have more than one of them? I suspect I'm missing something fundamental, because I'm very new to all of this, so if you can point it out, I'd be much obliged. Specifically, I can easily understand how to solve this kind of problem if we were working at the level where the MMD infrastructure was available, but since Dan tells me that that is above all of this... well, basically, how does it work? Is the situation where you have two vendors who both want to install call-backs for the same thing simply a "I'm sorry, but we don't support that" situation?

However, before referencing that post, I have to ask a few questions to try to deal with the current inadequacy of my understanding of Parrot exception handling:

I have a basic idea of how exceptions work at the level of continuations, inside of the Parrot machine, but can someone please explain how they work (or tell me where to read) at the level of the Parrot C runtime?

Furthermore, how are we addressing (if at all) Aaron's point about languages which don't have the most impressive exception handling in the world?

Finally, (and I'm just thinking about charset stuff here), exceptions frequently involve a bit of string processing. So if the charset/encoding code starts throwing exceptions, how do we write the string processing that those exceptions do so that further exceptions aren't thrown? Is Parrot like C++ where if an exception handler generates a second exception, the runtime immediately calls abort()? If not, how do we handle this situation, or another one like it?

Does this relate at all to the continuations-don't-cross-the-C/Parrot-interface rule?

Thanks for any help or pointers that you can give on this topic,
Michael

Reply via email to