Are these errors due to no matched routes found? Kitura sends 404 Cannot GET /some/endpoint by default if no middleware/handler for a route was found, or if none of the found middleware/handlers sent data.

It might be that second option (none of the middleware/handlers sent data), but it would be nice to know why that happened. Some examples I encountered include:

• A typo in a stencil file did not log an error, just "Cannot GET ..."
• When using CredentialsFacebook, if there is no returnTo address set (meaning I willingly navigate to /login/facebook instead of being redirected there because of failed authentication) I get a "Cannot GET /login/facebook/callback" response instead of a message saying there is no returnTo address set.
• Registering a template engine on a subrouter didn't work. See #1070

Can I add some weight to this issue? I have wasted hours trying to debug even the simplest bugs, simply because Kitura does not print any errors in its log. I am using HeliumLogger.use() as in the sample code, but every time an error is thrown, Kitura swallows it and simply returns "Cannot GET ...".

I have tried using router.error as per @shmuelk 's suggestion but that only works when my handlers set response.error explicitly. Wouldn't it make more sense if Kitura did this by default when a handler throws an error?

I did notice there's a line that sets the error in RouterMiddlewareWalker.swift but that seems to be unrelated as this line gets executed only after the default 404 response is sent.

I figured out the cause of my problem.
I (and lots of people with me I assume) have the habit of starting handlers with:

defer {
  next()
}

When a handler throws an error, that deferred next() causes the remaining handlers to be invoked and the response to be sent. These remaining handlers include the error handler, but it gets skipped as there is no error set yet. Only after the response has been sent, does the catch in RouterMiddlewareWalker.swift gets executed and response.error set.

So now I'm wondering if I'm using next() in the appropriate way. I did notice next() has to be called for a response to be sent. Since RouterMiddlewareWalker.swift includes an invocation of next() in its catch clause, should I just use next() instead of defer { next() } and assume that is enough to ensure next gets called in all cases?

I've found that I need to put a breakpoint on this line to find errors. Could we just add logging to this one line?

https://github.com/IBM-Swift/Kitura/blob/master/Sources/Kitura/RouterMiddlewareWalker.swift#L67

            } catch {
                response.error = error
                self.next()
            }

@bridger What did you end up doing? With my custom error class I have an enum MyServiceError which for each error has an associated description and status error code. But this doesn't cover errors thrown by Kitura.

// Handles any errors that get set
    router.error { request, response, next in
      let errorDescription: String
      if let error = response.error as? MyServiceError {
        errorDescription = error.debugDescription
        response.status(error.errorStatus)
      } else if let error = response.error {
        errorDescription = error.localizedDescription
      } else {
        errorDescription = "Unknown error"
      }
      try response.send(json: JSON(["error": errorDescription])).end()
    }

@christiancompton can you pick this up?

As I play with 2.0, I'm seeing a limitation with codables. If I want to return a custom object in the case of an error. Rather than returning MyCodable, I'd like to return something like { "error": "this is the reason it errored"}.

router.post("/endpoint") { (codables: [MyCodable], respondWith: ([MyCodable?], RequestError?) -> Void ) in
      if !codables.isEmpty {
        do {
          let newCodables = try self.createOrUpdate(codables) // add to db
         respondWith(newCodables, nil) // return successfully updated models
        } catch {
          respondWith([], .internalServerError) // here i'd like to return an error obj rather than a MyCodable
        }
      }
      respondWith(codables, nil)
    }

I guess I could solve this by creating a Codable which contains a variable for data and one for status.

So...

{ 
 "data" : [ { "id": 1}, { "id": 2}, {"id": 2} ],
 "status": { "success": 1, "message" : "this is where an error msg could go on failure" }
}

Maybe this is the way to do things, though it adds a bit of complication to my api