On Fri, 26 Jul 2013 14:40:47 GMT, Manu Evans wrote:
(...)
If you asked me, I would say the former, since you can perform that enforce in the outer scope yourself if you like.
I guess I'm having a lot of trouble visualising how to write nice looking code with extensive use of exceptions.
If simple form handling logic is potentially throw-ing all over the place, what is the typical structure/flow to handle errors gracefully?
Are there any idiomatic examples of this sort of code?I must confess, when I write C++, I always supply the compiler option to disable the exception handler ;)
I find comparing strings against null to be far simpler and more readable... but maybe that's just me.
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.