wildcard-api: Swallowing of errors

Hi there,

Loving the simplicity of this library. I’ve just got a couple issues I’d like some clarification on.

How do I catch errors that occur inside my async function for my endpoint.

For example:

import { endpoints } from "wildcard-api";

endpoints.runThing = async function({ argument }) {
  doSomethingWithArgument(argument); <-- This throws an Error
};

These errors are being swallowed and handled by Wildcard API, and the only result I get back from my request is:

HTTP/1.1 400 Bad Request
Content-Type: text/plain; charset=utf-8
Content-Length: 51
Date: Tue, 05 Mar 2019 14:29:25 GMT
Connection: keep-alive

{"usageError":"Endpoint could not handle request."}

Response code: 400 (Bad Request); Time: 49ms; Content length: 51 bytes

I would like to wrap my entire API in my own error handling, as I return certain structures of JSON from all my API endpoints for my client to handle as it likes. This includes uncaught errors in my API code - as of now I have no way to intercept that error and return my own structured response.

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 47 (29 by maintainers)

Commits related to this issue

#3 add statusCode and body to context — committed to brillout/wildcard-api by brillout 5 years ago
#3 add option onNewEndpointResult - wip — committed to brillout/wildcard-api by brillout 5 years ago
#3 add option onNewEndpointResult - wip — committed to brillout/wildcard-api by brillout 5 years ago
#3 add option onNewEndpointResult - wip — committed to brillout/wildcard-api by brillout 5 years ago
#3 allow user to intercept errors — committed to brillout/wildcard-api by brillout 5 years ago

Most upvoted comments

Okay cool. Interested to hear what you have put together on the next walk 😃

lostpebble on Sep 28, 2020

There is a legacy reason why Wildcard formats its own errors but I don’t think it’s required anymore, I’ll reevaluate this. And you’re right I should and I will reduce chars and console calls to a minimum. Thanks!

brillout on Sep 24, 2020

people will expect their endpoints to throw errors completely instead of them being swallowed by wildcard

Agreed and Wildcard actually never swallows errors. All uncaught errors happening in your endpoint function are always printed in Node.js’s stderr.

I find libraries that swallow errors super annoying. Swalling errors is a no-go.

That said, and as we agreed earlier, errors should not propagate to the browser.

I have plenty of backend code which throws errors on purpose given certain situations

Sorry, I wasn’t very clear: I was speaking of uncaught errors. Caught errors are perfectly fine.

Is there a reason why you need to take control of catching the errors?

Yes, to make Wildcard easier. My first and foremost goal with Wildcard is to make it easy. I’m fairly happy with the ease of https://github.com/reframejs/wildcard-api#error-handling (Note that re-rewrote the whole section yesterday. It should be easier to read now.) But maybe I’m missing something here.

How would I deal with status code things now?

Don’t deal with them at all? I believe that Wildcard abstracting away the HTTP protocol from you is a good thing. I can’t image a situation where you’d need to deal with status code. By wrapping your endpoint functions and wrapping your endpoint calls, I believe you can achieve anything you want without ever dealing with HTTP stuff.

I need to remember to wrap every single method

The trade off here is simplicity VS convenience. Agreed, wrapping every endpoint function is annoying. But on the other hand adding not-strictly-needed features to Wildcard makes Wildcard less simple. Not sure what is more important here but right now I’m leaning more toward simplicity.

Instead of wrapping every endpoint function, maybe you can wrap the function calls that throw the expected errors you want to catch in the first place?

brillout on Jun 7, 2019