When I see an exception like this, it doesn’t seem easy to identify which exception this is. How can I catch it? I suppose it’s some kind of exn:fail? and most likely file system related. draft.rkt> (average game-round 1000) exception raised by error display handler: flush-output: output port is closed; original exception raised: display: output port is closed

Another question I have is how I could take (current-output-port) and connect it, say, to /dev/null. (My objective is to ignore the io transfers.) I’m on Windows, though. I don’t have /dev/null. I’d like all bytes that go to (current-output-port) to just be ignored, so I see no effect of applications such as (displayln …). (I tried closing the current-output-port, but that doesn’t seem the best thing to do here.)

My best solution has been to tuck it away in a string. (let ([dev-null (open-output-string)]) (parameterize ([current-output-port dev-null]) (proc (watch-game (new-game seed)))))

https://docs.racket-lang.org/reference/port-lib.html?q=no-where#%28def._%28%28lib._racket%2Fport..rkt%29._open-output-nowhere%29%29

Well, it looks like you change error-display-handler and it’s buggy. error-display-handler is used for error reporting, so that’s the best it can do

Aside from the issue that sorawee raised, a lot of the time it isn’t clear what exn? is being raised. If I can recreate the error conditions I will make some mock code like (with-handlers ([exn? displayln]) (something-that-makes-the-error))

and see what comes out

Thanks. That’s helpful.

It looks like typed/racket does not support “generic interfaces” for structs. How do I keep up-to-date on development in that area?