On Fri, 26 Jul 2013 16:25:50 GMT, Sönke Ludwig wrote:

I'm right there with you. I also never used exceptions in C++ for various reasons and took a long time until I accepted the fact that so many things in D's runtime and standard library depend on them that it doesn't make sense to actively avoid them (however, I still fear I might regret that when looking at the state of non-x86 platforms). Funnily, the thing that made me actually start using them was to make the code look cleaner. I think I looked at a hand written D parser and was impressed how clean that code looked compared to my already clean C-style code.

The good thing is that usually you don't have to care about those exceptions, as long as important cleanup code properly uses scope(exit) or similar means. I have a few places like the following, though, where an explicit try-catch is used: 

void handleSubmittedForm(HTTPServerRequest req, HTTPServerResponse res)
{
	try {
		// read form values
		// validate values
		// perform action
		res.redirect("http://page/displaying/results");
	} catch (Exception e) {
		req.params["error"] = e.msg;
		// prints the error message
		renderFormPage(req, res);
	}
}

It helps a lot to keep the error handling code short and readable. But on the other hand you are absolutely right that if opDispatch throws an exception, the get-like behavior cannot be achieved in a sane way ("insane" meaning catching the exception and using a default value). On the other hand I don't like that failures could easily go undetected if the return value has to be explicitly checked. What do you think of a vibe.http.form-like approach? I somehow like the idea of having a low-level API and a higher level layer for maximum convenience to sidestep such issues.

The form approach is definitely interesting, but again, it implies that I can't handle particular missing args distinctly, which i do. It kinda implies a singular error state for missing args.
Also, what if I'm combining arguments taken from POST and from the URL? How will form deal with that? In my current situation, I'm taking arguments from the url, post, and also "/blah/:arg" path args...

Additionally, all this talk of exceptions, and the form approach, all make one important presumption... that it is an ERROR case that an argument is missing. It's not necessarily an error, that argument might have been optional, maybe it has some default... can be implied?

In my case, it's rarely an actual error case if something is missing, and if it is, it almost certainly requires very context specific error handling/reporting, which doesn't work either in the context of a single outer exception handler. The errors are specific, and need to be handled specifically :/

So... my code ends up looking like: 

if(req.args.myArg)
  // do soemthing if myArg is present
else
  // maybe i can default it, or handle missing myArg explicitly

I'm writing a web API, but even in the case of a typical webpage, consider a sign-up form; some fields are always optional, if you miss something that isn't optional, some red text "You forgot this!" appears next to the appropriate missing item for instance... that's quite context specific.
You never get redirected to a webpage that says "you made an error somewhere in the form, please try again" ;)