VRT_fail()

[Poul-Henning Kamp]

I have worked on the handling of near-fatal errors in VCL.

"near-fatal" errors are things like running out of workspace, or
doing silly things like:

	set req.url = "";

Where we cannot continue, but don't need to panic the worker process
because no state outside the work at hand have been corrupted.

In practice this works by setting ctx->handling to VCL_RET_FAIL and
having the VCC compiled code check if that happend after each
statement executed (a very cheap check btw.)

To trigger a VCL failure use VRT_fail() with a one line usable
message.

The fmt+args given to the VRT_fail() function will be VSL'ed as
VCL_Error or in the case of vcl_init{} spit out in the CLI.

And now the footnotes.

Right now failure in the backend side of VCL just fails the fetch,
with no diagnostic available as to why on the client side.  This
is a general problem not special to VRT_fail().

On the client side failure sends you to vcl_synth{}, but the bugwash
yesterday expressed a preference for a new dedicated vcl method for
this, so dont get too attached to this bit.  (Failures in vcl_synth{}
summarily close the client connection)

We need a generic function on top of VRT_fail() for workspace
overflows, so the diagnostics don't end up all different.  That is
yet to come.

I've been wondering if we should record the VCL-coords (file,line,char
like in VCL_count) of the failures in the VCL_Error() message, input
welcome?

Finally, because we only check for failure between handling, expression
evaluation can chew on for quite some time before it gets there.  We
need to think/study that a bit, before we decide if something more
radical is called for.

Otherwise, have at it, (and please use logexpect to check that the
messages are indeed in VSL)

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.