0

I have a server which receives requests that I have to parse in order to get the parameters for the request handler to use. Also, both the parsing and the request handler could fail in some way (e.g.: for the parser, a parameter is missing; for the req. handler: some error in a database), hence the "status" in the code below. The request handler of course gives some kind of response which I then have to send back to the client.

So I'm having trouble deciding which of the following options I should use in my "main", because I want to keep the parser separated from the handler:

1) 

parser.parse(request,&param1, &param2, &status)

handler.handle(param1, param2, &response, &status)

2)

status = parser.parse(request, &param1, &param2)

status = handler.handle(param1, param2, &response)

3)

Params params = parser.parse(request, &status)

handler.handle(params, &response, &status)

4)

status = parser.parse(request, &params)

status = handler.handle(params, &response)

5)

parser.parse(request, &params, &status)

response = handler.handle(params, &status)

6) etc., some other combination

(Params would be some kind of container for the different parameters, so for each type of request I would have a different "Params" type. Also, the "&" could mean pointer or reference, I'm using c++, but it's not relevant to the question)

Which is the easiest, clearer, best, ..., whatever?

*** There are plenty of similar questions, but none include the "status" part, so I can't make my mind yet

Chrischpo
  • 145
  • 1
  • 11

1 Answers1

0

This is not really a language-agnostic as it dependent on language features. For example, in Java I would do this like:

try {
    Params params = parser.parse(request); // parser.parse will throw ParseException if something wrong
    Response response = handler.handle(params); // handler.handle will throw HandleException if something wrong
    // send response to the client (status 200)
} catch (ParseException e) {
    // Send parse error to the client (for example: status 400 with e.getMessage() as message)
} catch (HandleException e) {
    // Send handle error to the client (for example: status 500 with e.getMessage() as message)
}

So the status is just an exception if it is bad status and no exception if it is good status. This can be custom exception with status field for more detail.

If programming language can't use the exceptions, then you can use pass by value (&status) for example. But don't pass the result, returning the status. Return the result. The result of parse is parsed params, not the status.

Ruslan Stelmachenko
  • 4,987
  • 2
  • 36
  • 51
  • 1
    The thing is, an error is not necessarily an exception. For example, if a user wants to login with a wrong password, I wouldn't say that is an "exception". Here the Response would be a token, and it doesn't seem ok to return a null token if the password is wrong. – Chrischpo Jun 11 '16 at 20:51
  • 1
    If a user tries to login with a wrong password, it is definitely an exception, which should resolve to 401/403 http status. And password-checking function will not return `null`. It will throw an exception (returning nothing). Do you know how exceptions work? If the function throws an exception, it not returns `null`. It returns nothing and code execution flow jumps to `catch` block. – Ruslan Stelmachenko Jun 11 '16 at 21:10
  • 1
    Yes, I know how exceptions work. I just don't think a wrong password is an exception, as it is not exceptional at all, it is very common for a user to enter a wrong password. So what I meant was that in your code there is no way to tell if something went wrong but didn't throw an exception. – Chrischpo Jun 11 '16 at 21:25
  • 1
    Сommonness of exception does not make it not an exception. :) It is common practice to make some set of exceptions which method could throw. Check, for example JAX-RS's [NotAuthorizedException](https://jax-rs-spec.java.net/nonav/2.0-rev-a/apidocs/javax/ws/rs/NotAuthorizedException.html). Or [this](http://stackoverflow.com/questions/583973/jax-rs-jersey-how-to-customize-error-handling) answer. Or Spring's [BadCredentialsException](http://docs.spring.io/spring-security/site/docs/current/apidocs/org/springframework/security/authentication/BadCredentialsException.html). It's just how it works. – Ruslan Stelmachenko Jun 11 '16 at 22:29
  • I'm inclined to agree with @Chrischpo ... Exceptions should be used for ***exceptional*** circumstances. Incorrect password is hardly exceptional. In fact, if you're security conscious, you would have a number of specific use-cases dealing with authentication failure (not incorrect password): logging, tracking retry counts, account lockout. (This is not the sort of code you should be calling from with a **catch** block.) – Disillusioned Jun 20 '16 at 08:51