best practices for logging in a Happstack application

[Norman Ramsey]

I am writing a new application and am interested in logging as one way of debugging it.  I also might like to gather information about how the application is used.

I found an old blog post that suggested happstack applications should log using hslogger, aka System.Log.Logger.  This requires an IO action, which is fine, but I am wondering if anyone here has ideas about best practices for logging using combinators.  I would rather not just drop down log calls everywhere; it feels too much like C programming.  I figure with higher-order functions there must be a better way to manage logging.  Any ideas?

[dag.od...@gmail.com]

Unrelated, but I posted a new comment on your SO question (duno if you get a notice for that? I didn't for your comment.):

http://stackoverflow.com/questions/12047656/can-a-session-cookie-be-sufficient-for-authentication#comment16175769_12064665

As for logging, hslogger is used by default for logging requests in Happstack, but it's just a default if you use nullConf and not a hard requirement. For Happstack 8 hslogger will most likely be replaced with something else. So for your own logging you can use whatever, although if you're using the hslogger setup for request logging it might be neat to be able to configure all logging together, with a single package. Not sure what kind of logging combinators you're looking for, though? For debugging it might be more useful to use things like traceStack/+RTS -xc, and compile with -prof -fprof-auto (assuming GHC 7.4+). This produces stack traces similar to those in other languages. Or are you looking for something else entirely?

On Fri, Aug 24, 2012 at 2:21 AM, Norman Ramsey <fells...@gmail.com> wrote:

I am writing a new application and am interested in logging as one way of debugging it.  I also might like to gather information about how the application is used.

I found an old blog post that suggested happstack applications should log using hslogger, aka System.Log.Logger.  This requires an IO action, which is fine, but I am wondering if anyone here has ideas about best practices for logging using combinators.  I would rather not just drop down log calls everywhere; it feels too much like C programming.  I figure with higher-order functions there must be a better way to manage logging.  Any ideas?

--
You received this message because you are subscribed to the Google Groups "HAppS" group.
To view this discussion on the web visit https://groups.google.com/d/msg/happs/-/ejFKDO7P6CYJ.
To post to this group, send email to ha...@googlegroups.com.
To unsubscribe from this group, send email to happs+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/happs?hl=en.

[Petter Bergman]

For debugging, I have user Debug.Trace which I find very practical. It might be a lot like C programming though, but I think this might be less of a problem if you use it for debugging only and use a different, more Haskell-y, way of  logging for other purposes.

2012/8/24 Norman Ramsey <fells...@gmail.com>

I am writing a new application and am interested in logging as one way of debugging it.  I also might like to gather information about how the application is used.

I found an old blog post that suggested happstack applications should log using hslogger, aka System.Log.Logger.  This requires an IO action, which is fine, but I am wondering if anyone here has ideas about best practices for logging using combinators.  I would rather not just drop down log calls everywhere; it feels too much like C programming.  I figure with higher-order functions there must be a better way to manage logging.  Any ideas?

--

[Norman Ramsey]

I should clarify that I'm perfectly good using QuickCheck and Debug.Trace as needed during development.

But during deployment I want some logging going on so that if something strange happens, there will be bread crumbs.