Re: Bug notices?

In <29va09INN1k3@emory.mathcs.emory.edu> johnl@informix.com (Jonathan Leffler) writes: >>From: Jack Parker <jparker@hpbs2561.boi.hp.com> >>Subject: Re: Bug notices? >>Date: Mon, 18 Oct 93 14:51:00 MDT >>X-Informix-List-Id: <list.2965> >> >>Andrew Burt (aburt@du.edu) said: >>> In my continuing quest to find responsive support from vendors :-) I'd >>> like to propose that Informix post bug lists to this group. >See my previous comments about not using RETURN in a report. In fact, it >may yet get outlawed**. And the GOTO alternative I saw suggested is >equally ill-advised. What havoc, pray tell, can the goto solution cause (other than it being ugly, of course)? [Re bug#s] >Yes, it's a serial. Yes, there's a lot of traffic. I just checked and the >current highest bug number is 21036 (at 1993-10-18 16:00 PST). Most of >those bugs are in internal development versions, not in field versions. >You wouldn't really want to have to wade through that list of bugs, I >assure you. At the very least, you'd only want to know about bugs in field >versions of the product. No, of course nobody external much cares about the internal ones. But I'm sure they could be skipped. I'd be most happy to wade through a list of released-product bugs; I imagine they'd be grouped by product (with pointers to the first instance for bugs the affect multiple products). I was thinking something like: === RDS 4.1 === Fixed: Bug#1111 Wombat stomps on stack Fixed in RDS 5.0 ... Status: Bug#2222 Aardvark won't alter index New workaround found: use wombat to... ... New: Bug#20562 Return in report causes next row to be skipped blah blah blah, details, suggested workaround, etc. ... Bug#33333 Foo in bar causes blurfl description, etc. ... === ESQL/C 5.0 === ... Bug#33333 Foo in bar causes blurfl ** See RDS 4.1 ** >** Actually, it probably won't get outlawed -- it'd break too much code. > But it might well be documented that using RETURN in a report can screw > up aggregates, line number counts, page headers, page trailers, and > general report logic, not to mention the next row, and is generally > about as unreliable a construct as you can get. The more I look at what > a RETURN can do, the less I like them. Wouldn't it be better just to _fix_ return in reports? "The code is too ugly to allow that" is not an acceptable defense. (In defense of this, consider that any report with return could be rewritten without it: if foo then return end if more code becomes if not foo then more code end if including surrounding the code in each following "after group of", etc.) It might also be useful to have another construct, "continue report" say, that skips the rest of the current section (on every row, after group of, etc.) but jumps to the next one. -- Andrew Burt aburt@du.edu "But if he was dying he wouldn't bother to carve "Aaaaargh", he'd just say it."