Decouple cascade from versioning

[skwp]

Why is the thing that controls whether errors are cascaded to rails tied to the version declaration? I'm trying to build a versionless api that also doesn't hit rails if I happen to type in the wrong path on the client. The cascade declaration doesn't seem to work without a version:

version :cascade => false

Makes all paths in my api 404. Some insight here would be nice before I attempt to change/pull request something that will not be merged upstream :)

[dblock]

TBH I am not 100% sure why this was designed this way. I am open to a different design that's more generic, and in some extreme cases even if it may break backwards compatibility (although in this case I am sure we could preserve both). I definitely think that version :cascade => false is weird. There's got to be a different way to express the same.

[skwp]

how about just

cascade false

We could keep the version syntax for backwards compatibility with a deprecation warning
I would also consider naming it something more obvious like

reraise_errors false

At least I think that's what it's doing right? Cascading means reraising so that rails can trap it? Whereas not cascading means the error is trapped by Grape?

[dblock]

Since the header is X-Cascade, I think cascade is a reasonable name.

Cascade is not about errors. It's about telling the routing stack that you haven't handled the request and that the next handler should handle it instead of stopping there. This SO has a perfect explanation.

[dblock]

So I'll attempt a theory why the implementation was tied in versionning. The only time we had to negotiate whether to handle or not to handle the request was in versionning. But you're doing no versionning, so that theory is moot.

[dblock]

Implemented in 3b6e37a, please take a look.

[skwp]

thanks (two years later)