These are chat archives for supercollider/supercollider

4th
Jun 2017
Patrick Dupuis
@patrickdupuis
Jun 04 2017 19:44
@snappizz you there?
i'm looking at Bus.sc and I am wondering about why sometime we have error("some error msg"); ^nil and sometimes we don't have the nil after the error.
like with set and setMsg
i know that without the ^nil the object is returned
Patrick Dupuis
@patrickdupuis
Jun 04 2017 19:49
I can see the logic behind choosing to return the object in this case
i wonder if it would be best to be explicit (maybe return ^this?)
im thinking about our style guide
Nathan Ho
@snappizz
Jun 04 2017 23:45
does a method return anything if there's an error?
Patrick Dupuis
@patrickdupuis
Jun 04 2017 23:45
what do you mean?
Nathan Ho
@snappizz
Jun 04 2017 23:45
it shouldn't... so i think those ^nils after errors are useless
ahh wait. so String:error prints an error message but doesn't actually exit
Patrick Dupuis
@patrickdupuis
Jun 04 2017 23:46
error("some message"); ^nil gives you
Some message
Nil
otherwise you get
Some message
Nathan Ho
@snappizz
Jun 04 2017 23:47
but if you use Error(...).throw, it does exit the method
Patrick Dupuis
@patrickdupuis
Jun 04 2017 23:47
Buffer(...blah)
MethodError give you a proper error
error() post a message only
yes, with .throw
Nathan Ho
@snappizz
Jun 04 2017 23:48
i don't see any good reason why these methods use "beep".error; ^nil instead of just throwing something
maybe they predate throwing? who knows
Patrick Dupuis
@patrickdupuis
Jun 04 2017 23:48
maybe...
i think "beep".error is like a warning
but we also have "beep".wanr
warn
Nathan Ho
@snappizz
Jun 04 2017 23:49
yeah, so basically String:error is stupid
Patrick Dupuis
@patrickdupuis
Jun 04 2017 23:49
i think the coloring of the text is different than warn
not sure though
but yes, it seems redundant
Nathan Ho
@snappizz
Jun 04 2017 23:50
it's a bad idea from a UI perspective to display an error message if no actual exception was thrown
Patrick Dupuis
@patrickdupuis
Jun 04 2017 23:50
what about warning the user?
is that bad design also?
in this case, at least
Nathan Ho
@snappizz
Jun 04 2017 23:51
in this particular case, i'd just make them errors, unless there's some reason they aren't real errors
Patrick Dupuis
@patrickdupuis
Jun 04 2017 23:52
since nothing bad happenned, maybe just a warning "hey! you're trying to free a already freed buffer!"
an error would seem too dramatic
we need a warning, or a very clear and informative error
proper errors are pretty verbose
Nathan Ho
@snappizz
Jun 04 2017 23:54
Bus.free already warns, so it's ok
Bus.control, Bus.audio, and all the Bus.set* methods need to be fixed
Patrick Dupuis
@patrickdupuis
Jun 04 2017 23:55
yes, Bus and Buffer too
i would like to work on it, if that's ok
Nathan Ho
@snappizz
Jun 04 2017 23:55
sure thing
Patrick Dupuis
@patrickdupuis
Jun 04 2017 23:56
ok, i did some work already in my fork
experimental branch
i did string errors everywhere
wasn't sure what was best
i copied what i found in Bus.sc
patrickdupuis/supercollider@372d364
maybe you can take a look, and we can figure out what to do
Nathan Ho
@snappizz
Jun 04 2017 23:58
that links to an unrelated merge commit
Patrick Dupuis
@patrickdupuis
Jun 04 2017 23:59
oh..
patrickdupuis/supercollider@16c1323