Re: [racket-users] exn-string
I think user-friendly 500 page should be designed separately just as web devs do for 404 page. In practice, a user happens to meet an uncaught runtime exception, and he's browsing a buggy website, perhaps he do not have the will to report the problem, nor the way to report it. Finally, devs will fix it certainly by checking a place, say, logging system, where saved this exception rather than asking user for the screen snapshot. So I think it's devs' fault if they forget to hide their exceptions. This situation should never happen in a high-value project. On Mon, May 25, 2015 at 11:16 PM, Greg Hendershott greghendersh...@gmail.com wrote: Maybe I'm over-thinking this and/or misunderstanding the use case, but: Should there maybe be a parameter to control whether exn-string returns anything interesting? And, should it be #f by default? Roughly, for example: ;; When current-exn-string-enabled? is #f -- the default -- ;; exn-string simply returns error. ;; ;; (The idea here is that net apps shouldn't provide this information ;; by default, exn-string is probably being used to provide debug ;; info, and this should be enabled intentionally not by default.) (define current-exn-string-enabled? (make-parameter #f)) ;; exn-string : (or/c exn any) - string (define (exn-string exn) (cond [(not (current-exn-string-enabled?)) error] [(exn? exn) (parameterize ([current-error-port (open-output-string)]) ((error-display-handler) (exn-message exn) exn) (get-output-string (current-error-port)))] [else (format ~s\n exn Admittedly, just because there's a switch to turn it on and off, doesn't mean people will use it. (Source: Use the web for a week and encounter .NET apps deployed to show debug stack traces on error.) But there should be a switch, so that people can forget to use it. :) Admittedly, most Racket web apps are probably not high-value targets, today. But they ought to be someday, so why not plan for that? Again, I'm sorry if I'm over-thinking this. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] exn-string
For the purposes of the Web server, I don't think that's the right thing to do. The right thing to do if you don't like the error display is to change the arguments to #:servlet-loading-responder and #:servlet-responder to print less, or just put with-handlers in your servlet and do something else. Jay On Tue, May 26, 2015 at 1:39 PM, Tony Garnock-Jones to...@ccs.neu.edu wrote: On 05/25/2015 11:16 AM, Greg Hendershott wrote: Should there maybe be a parameter to control whether exn-string returns anything interesting? And, should it be #f by default? That's an interesting idea. I know of examples where Racket error reports have disclosed sensitive information. Such mistakes can be extremely subtle and difficult to anticipate, and even skilled, experienced engineers make them. Perhaps, if a parameter is a good idea (I'm not sure it is), when it is #f, exn-string could yield an instructive message such as #error redacted to avoid accidental information leak; see documentation for current-exn-string-enabled? plus suitable RED FONT DANGER TEXT in the documentation making it clear to users that they should think about the contexts in which the resulting strings will be published. Tony -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Jay McCarthy http://jeapostrophe.github.io Wherefore, be not weary in well-doing, for ye are laying the foundation of a great work. And out of small things proceedeth that which is great. - DC 64:33 -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] exn-string
Amen On Tuesday, May 26, 2015, WarGrey Gyoudmon Ju juzhenli...@gmail.com wrote: I think user-friendly 500 page should be designed separately just as web devs do for 404 page. In practice, a user happens to meet an uncaught runtime exception, and he's browsing a buggy website, perhaps he do not have the will to report the problem, nor the way to report it. Finally, devs will fix it certainly by checking a place, say, logging system, where saved this exception rather than asking user for the screen snapshot. So I think it's devs' fault if they forget to hide their exceptions. This situation should never happen in a high-value project. On Mon, May 25, 2015 at 11:16 PM, Greg Hendershott greghendersh...@gmail.com javascript:_e(%7B%7D,'cvml','greghendersh...@gmail.com'); wrote: Maybe I'm over-thinking this and/or misunderstanding the use case, but: Should there maybe be a parameter to control whether exn-string returns anything interesting? And, should it be #f by default? Roughly, for example: ;; When current-exn-string-enabled? is #f -- the default -- ;; exn-string simply returns error. ;; ;; (The idea here is that net apps shouldn't provide this information ;; by default, exn-string is probably being used to provide debug ;; info, and this should be enabled intentionally not by default.) (define current-exn-string-enabled? (make-parameter #f)) ;; exn-string : (or/c exn any) - string (define (exn-string exn) (cond [(not (current-exn-string-enabled?)) error] [(exn? exn) (parameterize ([current-error-port (open-output-string)]) ((error-display-handler) (exn-message exn) exn) (get-output-string (current-error-port)))] [else (format ~s\n exn Admittedly, just because there's a switch to turn it on and off, doesn't mean people will use it. (Source: Use the web for a week and encounter .NET apps deployed to show debug stack traces on error.) But there should be a switch, so that people can forget to use it. :) Admittedly, most Racket web apps are probably not high-value targets, today. But they ought to be someday, so why not plan for that? Again, I'm sorry if I'm over-thinking this. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com javascript:_e(%7B%7D,'cvml','racket-users%2bunsubscr...@googlegroups.com'); . For more options, visit https://groups.google.com/d/optout. -- Jay McCarthy http://jeapostrophe.github.io Wherefore, be not weary in well-doing, for ye are laying the foundation of a great work. And out of small things proceedeth that which is great. - DC 64:33 -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] exn-string
I was thinking the parameter could be a handy runtime switch, defaulting to safe. However realistically there's probably a lot of other ground to cover when it comes to debug vs. production deployments. Maybe this needs a more comprehensive approach than nibbling away one switch at a time. Maybe a doc warning is sufficient: It is probably unwise to put this information in a network response (like a web page) in production. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] exn-string
On 05/25/2015 11:16 AM, Greg Hendershott wrote: Should there maybe be a parameter to control whether exn-string returns anything interesting? And, should it be #f by default? That's an interesting idea. I know of examples where Racket error reports have disclosed sensitive information. Such mistakes can be extremely subtle and difficult to anticipate, and even skilled, experienced engineers make them. Perhaps, if a parameter is a good idea (I'm not sure it is), when it is #f, exn-string could yield an instructive message such as #error redacted to avoid accidental information leak; see documentation for current-exn-string-enabled? plus suitable RED FONT DANGER TEXT in the documentation making it clear to users that they should think about the contexts in which the resulting strings will be published. Tony -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] exn-string
Maybe I'm over-thinking this and/or misunderstanding the use case, but: Should there maybe be a parameter to control whether exn-string returns anything interesting? And, should it be #f by default? Roughly, for example: ;; When current-exn-string-enabled? is #f -- the default -- ;; exn-string simply returns error. ;; ;; (The idea here is that net apps shouldn't provide this information ;; by default, exn-string is probably being used to provide debug ;; info, and this should be enabled intentionally not by default.) (define current-exn-string-enabled? (make-parameter #f)) ;; exn-string : (or/c exn any) - string (define (exn-string exn) (cond [(not (current-exn-string-enabled?)) error] [(exn? exn) (parameterize ([current-error-port (open-output-string)]) ((error-display-handler) (exn-message exn) exn) (get-output-string (current-error-port)))] [else (format ~s\n exn Admittedly, just because there's a switch to turn it on and off, doesn't mean people will use it. (Source: Use the web for a week and encounter .NET apps deployed to show debug stack traces on error.) But there should be a switch, so that people can forget to use it. :) Admittedly, most Racket web apps are probably not high-value targets, today. But they ought to be someday, so why not plan for that? Again, I'm sorry if I'm over-thinking this. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] exn-string
A new module sounds right to me. I was thinking `racket/exn-to-string` for just this function, but `racket/exn` sounds fine and maybe better. At Sun, 24 May 2015 08:01:23 -0400, Jay McCarthy wrote: I think it's a good idea. Where to though? A new racket/exn module? Jay On Sat, May 23, 2015 at 11:48 AM, Tony Garnock-Jones to...@ccs.neu.edu wrote: Hi all, I find myself using exn-string from web-server/private/util *a lot* in many of my packages. (I just counted eight!) Should we move it to core Racket, so I don't need to depend on a private subcollect of the web-server-lib package everywhere? It seems like something many programs, not just mine, will want to do. Tony -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Jay McCarthy http://jeapostrophe.github.io Wherefore, be not weary in well-doing, for ye are laying the foundation of a great work. And out of small things proceedeth that which is great. - DC 64:33 -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] exn-string
I think it's a good idea. Where to though? A new racket/exn module? Jay On Sat, May 23, 2015 at 11:48 AM, Tony Garnock-Jones to...@ccs.neu.edu wrote: Hi all, I find myself using exn-string from web-server/private/util *a lot* in many of my packages. (I just counted eight!) Should we move it to core Racket, so I don't need to depend on a private subcollect of the web-server-lib package everywhere? It seems like something many programs, not just mine, will want to do. Tony -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Jay McCarthy http://jeapostrophe.github.io Wherefore, be not weary in well-doing, for ye are laying the foundation of a great work. And out of small things proceedeth that which is great. - DC 64:33 -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
