On Friday, 7 February 2014 at 14:26:48 UTC, Marc Schütz wrote:
or a remote server. However, I can't see how these are
fundamentally different from invalid user input, and indeed,
there's often not even a clear separation, e.g. when a user
asked you to read a file they don't have access to.
I agree. Any situation where it makes sense to say:
"Ouch, this is not going to work out, roll back, roll back, let's
move out of this module! We need to try a different approach. We
are not going to continue with anything productive down this
lane, lets go back to the context and get into a new direction."
is suitable for exceptions and it makes code reuse, evolution and
modification to error reporting easy.
- validation and veracity checking
- authentication failures
- database failures
- transactional retries
- serious allocation issues
- timeouts
are all fiiine for exceptions.
You get to write a request handler like this:
{
auto sid = request.authenticate();
auto data =
validator(request.getPost('label1','label2','label3'));
auto key = model.create_and_put(sid,data);
response.writeJson(key);
response.status = 201;
return;
}
And you can change the error reporting at the request dispatcher
level rather than sifting through 20 different spaghetti-like
request handlers trying to figure out if you got it right:
{
auto sid = request.authenticate();
if (sid<0){
... return ...;
}
auto data = request.getPost('label1','label2','label3');
if (data){
data = validate(data);
if (data){
auto key = model.create_and_put(sid,data);
if (item){
auto ok = response.writeJson(key);
if(ok){
response.status = 201;
return;
}
....;
} else {
.... ;
}
} else {
.... ;
}
} else {
... ;
}
}
