Re: stp_exit change

[Martin Hunt <hunt at redhat dot com>]

On Wed, 2006-01-11 at 14:34 -0500, Frank Ch. Eigler wrote:
> 
> > Within the runtime, sometimes unexpected errors happen and there is
> > either no return value for the function of the translator doesn't
> > check it.
> 
> These both sound like bugs.

In at least one case I know of, yes. Other times, it may be OK. For
example, something like:

x = get_value();
...
int get_value() {
   ...
   if (something really bad and unexpected happens) {
	stp_error("bad mojo")
	return 0;
   }
   return val;
}

> On the contrary, I would rather the runtime assume as little as
> possible about translator code generation patterns.

I think we consistently disagree on this point. While the majority of
the runtime code should be self-contained and not care at all about the
translator, there is a need for functions that aid in the interface
between the two. For some reason you used to remind me over and over
that the runtime was supposed to be solely for the use of the
translator. So I have been surprised you haven't been sticking all kinds
of little functions and code chunks into it.

> > [...]  I recommend eliminating _stp_softerror() unless you can
> > explain the difference between it and _stp_warn().
> 
> Certainly: the "ERROR" vs "WARN" "stp_vlog" channel, plus the
The channel is the same.
> "WARNING" vs "ERROR" message from stpd.  The recently introduced "soft
> error" concept is different from a warning, in that a script may
> tolerate some limiting number of the former (and unwinds the offending
> probe), and does not treat the latter any differently from a printf.

I think an error that is ignored is a warning. Errors are always fatal.
Which leads us back into the discussion about 1379.