Yeah, this makes sense now.

I did a little more research just to make sure I understood what changed from 0.12 to 1.0, in case we need to address this again later.

Prior to 1.0, error handlers for HTTPException classes were only looked up by code. So if there wasn't a specific handler registered, it wouldn't fall back to a more general handler, which people found confusing. But it was possible to add a handler specifically for the 301 code and have different redirect behavior. Why you would do that, I don't know, but it was possible. And since RequestRedirect wasn't part of the werkzeug.exceptions.default_exceptions map, a handler for 301 wouldn't have matched it anyway.

I'm OK with saying that anyone who really wants to catch RequestRedirect should override handle_http_exception or url_map to do something different. Or if they want to redirect using exceptions, they can create their own class Found(HTTPException): code = 302 and add a handler for that.

Or if they want to redirect using exceptions, they can create their own class Found(HTTPException): code = 302 and add a handler for that.

One small comment on the above – if someone does want to redirect using exceptions in a view, they wouldn't use RequestRedirect anyway. It's documented as a thing to use inside Werkzeug routing.

Because RoutingException is not actually part of werkzeug.exceptions.default_exceptions, installing an exception handler for 302 (well, now it's 308) in 0.12 would not have caught RoutingExceptions anyway.