I understand entirely that this was not the sort of case you seemed to have in mind, but I'll follow up because I worry that, in the process of making a minimal example, I may have obscured the actual problem. "The fix can be easily located in [my] code" in the sense that it's clear that the error is not the fault of the library writer, but I'm not sure I'd say that it can be "easily located" in general — though obviously "easily" is a relative term, and, again, it is only having seen just how good a great error message can be that I can dream of a better world.
The problem with locating the error is more pronounced if the call to serve/servlet is not in the same module as the non-serializable value, and especially if the program being run incorporates several modules written in #lang web-server. In larger programs like that (unfortunately I don't have a great specific example to send right now) I have encountered error messages with which it has not even been entirely clear which module is to blame, let alone where within the module to start looking. (Perhaps there is, in fact, some way to extract this information from existing messages: all I can say is that there have been times when it has not been clear to me.) Also, I have not found a good way to get more specific messages through the contract system. Certainly "(kont #<procedure:...abort-resume.rkt:154:25>)" doesn't help much with tracking down the problem, and "#<procedure:...formlets/lib.rkt:17:2>", while it makes it sufficiently clear that the offending value was a formlet, doesn't tell me where the formlet is, or even where to start looking for it. If this were the first time I were seeing this error message, I might also be confused by the fact that stuff-url is not only not a function I called, I do not believe it is a documented part of the API. If there were some way of getting the error message to show, for example, which call to send/suspend failed (in this case: the one within get-date, which was called within start — it just happens that my tiny example only called send/suspend once), that would be a great improvement. But, again, I feel spoiled by the excellence of Racket's error reporting overall, and I suspect the incremental improvements I have in mind are easier said than done. -Philip P.S.: As I wrote this, I glanced at the implementation of stuff-url and saw that it generates these error messages by using a "with-handlers" form that runs a regexp against the message of any "exn:fail" it catches. Perhaps it would be worth creating an exn:fail:serialize, as I know I have also written regular expressions against that error message … I could even imagine something like a lazily-enforced "serializable/c", especially as "serializable?" doesn't check the contents of nested values. All just pipe dreams, though! On Mon, Jan 2, 2017 at 9:12 AM, Matthias Felleisen <matth...@ccs.neu.edu> wrote: > > On Jan 2, 2017, at 7:25 AM, Philip McGrath <phi...@philipmcgrath.com> > wrote: > > > So why have I not complained about this? > > First, most generally, because the bug is clearly my fault. > > > > Hi Philip, thanks for this example. What Robby and I had in mind are calls > to errors inside a library that baffle client programmers. When (1) it is > clear from the error message how to fix the mistake and (2) the fix can be > easily located in your code, there’s no problem. Our goal is to eliminate > situations when either (1), (2) or both are unclear due to error "from the > guts”. > > > hank you for all of the thought you all have given to useful error > messages, and for contracts specifically. > > > We owe this aspect of our work to our original goal of spreading the word > about reading, ‘riting, ‘rogramming but it turns out, it’s generally > useful. > > Errors matter, POPL 2002 :-) > > — Matthias > > -- 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.
