feature request : catching errors
it would be great that the [error] object avoids errors to print in the max
window when activated.
Guillaume Evrard schrieb:
> it would be great that the [error] object avoids errors to print in the
> max window when activated.
Its an old request, and I second it, though I don’t think it will ever
happen. It would only make sense if the error object could work patcher
specific, catch only the errors of the patcher it is in…
I’d love both features…
> it would be great that the [error] object avoids errors to print in the max window when activated.
Also nice would be to deactivate "harmless" errors from showing up from specific objects, should one want to. My errors with multislider: "slider 1024 out of range" and "jit.net.send: dropped a matrix" are fine for testing, but aren’t needed in a finished app. I know you can eliminate the Status window, so that’s an OK workaround.
But this is probably a much broader topic… when do you want errors to show, and when not? They can help you fix things, but some things just are the way they are—bandwidth issues causing matrix drops, for one.
Admittedly, the multislider messages (or similar) indicate a problem in the patch which should be looked at, but often it’s a subtle problem regarding how long it takes the object to set itself to a new list size versus being ready to handle the new data lists coming in. It’s been tough to track down and has caused some crashes; that’s probably my patching, but often it’s tough to tell. (delay perhaps? yes of course I’ve experimented, sometimes with success.)
When things are more or less working, I still get errors but no crashes. Seems like a fine line there sometimes…
The worst one of them all is without a doubt the coll:finished, x lines message. We typically load 50-100 colls from a savedir so the max window is constantly a mess