!standard 11(2/3) 11-06-19 AI05-0258-1/01 !standard 11.4.1(10.1/3) !class binding interpretation 11-06-19 !status work item 11-06-16 !status received 11-04-29 !priority Low !difficulty Easy !qualifier Omission !subject Preserving information in an exception occurrence !summary ** TBD. !question How many ways can an exception occurrence be created? 11(2/3) says that there are three "manners" that an exception can be raised. 11.4.1(10.1/3) talks about those and "other ways". Is the list in 11(2/3) really exclusive? What happens for occurrences that are propagated between tasks, streamed in out (including by being marshalled across a remote call) and the like? For instance, is it OK to truncate the message when it is streamed? This behavior was unspecified in Ada 2005 and before; did we mean to specify it? Aside: there ought to be some wording that propagation preserves the contents of an exception occurrence. !wording ** TBD !discussion !ACATS Test ** TBD. !ASIS ** TBD. !appendix [Part of the editorial review of Erhard Ploedereder:] 11.4.1 10.1/3 penultimate sentence: > For an occurrence originally raised for some other reason, the > message is an unspecified string. lazy wording "for some other reason". In "if things-go-bump then raise fright; end if;" things-go-bump is the reason for the exception, not the raise statement. According to 11 2/3(2.sentence) only implicit raises are left. If indeed 9.5.2(24) is an extra case, 11 2/3 needs fixing, too, but presumably it is but a propagation and hence not an extra case. Footnote: I would prefer implementation-defined string. Oh well. Rewrite: ----- For an occurrence originally raised by a language-defined check, the message is an unspecified string. **************************************************************** From: Randy Brukardt Sent: Friday, April 29, 2011 12:57 AM > 11.4.1 10.1/3 penultimate sentence: > > For an occurrence originally raised for some other reason, the > > message is an unspecified string. > > lazy wording "for some other reason". In "if things-go-bump then raise > fright; end if;" > things-go-bump is the reason for the exception, not the raise > statement. Ugh, I suppose you are right. > According to 11 2/3(2.sentence) only implicit raises are left. If > indeed 9.5.2(24) is an extra case, 11 2/3 needs fixing, too, but > presumably it is but a propagation and hence not an extra case. > Footnote: I would prefer implementation-defined string. Oh well. I don't quite buy this; anything that creates an occurrence has an Exception_Message; it doesn't have to come from a raise of an exception. In particular, it is possible to stream an occurrence, and I don't think the language intended to require that the message is preserved unchanged. (Some implementations truncate occurrences when they are copied or streamed; Janus/Ada does that as the stack information could take up a huge amount of space otherwise. Also, most exception messages are pointers (if static) until an occurrence is copied; at that point the string has to be copied into the occurrence [because we can't stream or do I/O on a pointer] and that truncates it). > Rewrite: > ----- > For an occurrence originally raised by a language-defined check, the > message is an unspecified string. What about "new" occurrences from other source, at least WRT the current program? The Ada 2005 wording definitely left that unspecified -- maybe it was unintentional, but I don't want to change it without a full discussion (too late for that now, I think). And the Adam question (in AI05-0043-1) seems legitimate; 9.5.2(24.b) says that this is a new occurrence; it is *not* considered propagation. (Of course, AARM notes can be wrong, but it shows an intent.) Indeed, I can't find anything that clearly says that propagation is required to preserve the information in an occurrence. It seems like that should be said somewhere. And I know that a reraise doesn't preserve an occurrence (at least in Janus/Ada, it preserves parts of it, but it changes to reflect the reraise location so that can be traced if necessary). All-in-all, I don't think this is well-specified, and it hardly is worth specifying much (do implementers really make these things useless because they can?? I think it is more likely that they have a good reason for whatever they do). So, I'm making a minor tweak to this wording: "For an occurrence originally raised in some other manner (including by the failure of a language-defined check), the message is an unspecified string." This isn't ideal, but this isn't worth a lot of effort, either. **************************************************************** From: Erhard Ploedereder Sent: Friday, April 29, 2011 4:17 AM >"For an occurrence originally raised in some other manner (including by >the failure of a language-defined check), the message is an >unspecified string." This is fine with me to cover my "things-go-bump"-remark. But going that route, you also need to fix 11 2/3(2.sentence), since that one only names three "manners", two of which are already covered in the sentences preceeding this one. The only one left IS the failure of a language defined check. 11 2/3 knows of no other manner, but by your argument it should. ****************************************************************