Reimplement ScottyT in terms of ReaderT

[ocramz]

This would give us local, allowing to apply specific middlewares (e.g. authentication) only on given sets of routes (See #187 ).

Also it would let us unify the exception handling mechanism.

It's only a breaking change if we put the reader variable inside a TVar and some modifying functions gain a MonadIO constraint.

We can use the predicates defined here to inspect HTTP status codes and act accordingly (i.e. throw an exception or not): https://hackage.haskell.org/package/http-types-0.12.3/docs/Network-HTTP-Types-Status.html#v:statusIsInformational

---

It was ReaderT all along?

Always has been.

[ocramz]

@fumieval what do you think?

[fumieval]

ScottyT has nothing to with exceptions because it should never fail, as its sole purpose is to build a WAI application. For this purpose I think State-like monad is a better fit

[ocramz]

good points! While I'm a bit concerned by that "should never fail", I don't have a counterexample currently, so I'll close this.

…

On Sun, 15 Oct 2023 at 15:43, Fumiaki Kinoshita ***@***.***> wrote: ScottyT has nothing to with exceptions because it should never fail, as its sole purpose is to build a WAI application. For this purpose I think State-like monad is a better fit — Reply to this email directly, view it on GitHub <#340 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABNBDKHDCAJPC4SZV4RCK6TX7PR7VAVCNFSM6AAAAAA6A4NME6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRTGM4TGOBUGY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[fumieval]

If the route definition contains a mistake (e.g. get "/foo" defined twice), perhaps it should throw an error. It should not be caught anyway

[ocramz]

ok, closing this !