Hi,
that's a more general question. Do you raise some sort of illegal argument exepction on a method call with improper arguments? If not, why not? If yes, do you throw a custom exception or some from the base library? It doesn't seem a too common practice in Smalltalk. Best, Steffen _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
On 2/2/2015 11:16 AM, Steffen Märcker wrote:
> Hi, > > that's a more general question. Do you raise some sort of illegal > argument exepction on a method call with improper arguments? If not, > why not? If yes, do you throw a custom exception or some from the base > library? It doesn't seem a too common practice in Smalltalk. Typical practice is to *not* test argument type, the runtime system will typically return an error 'soon enough'. Most often that will be a MessageNotUnderstood exception, but that is not guaranteed... What you do see is testing for certain argument values (as opposed to types), one such use is in the base library to return a more precise exception. For instance SequenceableCollection>>first will first check the zero-th argument for emptyness before sending 'at: 1', which would fail anyway on empty collections. When your domain becomes complex I find it helpful to put such value checks in more places using a 'self assert: [....] ' construct, thus moving just slightly into the direction of contract based development. To answer your 'why not' I guess that is a matter of pragmatics: in stiffer typed environments like C, COM etc your app and associated state will crash hard when the wrong type is passed in, in Smalltalk your IDE would typically still be standing. So it is less of a problem here (essentially bacause it is handled by the VM abstraction). Reinout ------- _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Et oui, on se moque pas mal de la classe de l'argument, du moment qu'il répond à tout ce qu'on lui demande. Et on ne peut pas toujours savoir, au moment où on développe la méthode à quelle classe encore inexistante appartiendra l'argument futur. C'est quand même la base de Smalltalk. Bonne année à tous ! 2015-02-02 14:20 GMT+01:00 Reinout Heeck <[hidden email]>: On 2/2/2015 11:16 AM, Steffen Märcker wrote: _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Thanks Reinout and Vincent for your answers. I was just curios how others
handle such situations. =) Am .02.2015, 16:12 Uhr, schrieb Vincent Lesbros <[hidden email]>: > Et oui, on se moque pas mal de la classe de l'argument, du moment qu'il > répond à tout ce qu'on lui demande. > Et on ne peut pas toujours savoir, au moment où on développe la méthode à > quelle classe encore inexistante appartiendra l'argument futur. > C'est quand même la base de Smalltalk. > Bonne année à tous ! > > > > 2015-02-02 14:20 GMT+01:00 Reinout Heeck <[hidden email]>: > >> On 2/2/2015 11:16 AM, Steffen Märcker wrote: >> >> >> Typical practice is to *not* test argument type, the runtime system will >> typically return an error 'soon enough'. Most often that will be a >> MessageNotUnderstood exception, but that is not guaranteed... >> >> What you do see is testing for certain argument values (as opposed to >> types), one such use is in the base library to return a more precise >> exception. For instance SequenceableCollection>>first will first check >> the >> zero-th argument for emptyness before sending 'at: 1', which would fail >> anyway on empty collections. >> >> >> When your domain becomes complex I find it helpful to put such value >> checks in more places using a 'self assert: [....] ' construct, thus >> moving >> just slightly into the direction of contract based development. >> >> To answer your 'why not' I guess that is a matter of pragmatics: >> in stiffer typed environments like C, COM etc your app and associated >> state will crash hard when the wrong type is passed in, in Smalltalk >> your >> IDE would typically still be standing. So it is less of a problem here >> (essentially bacause it is handled by the VM abstraction). >> >> >> >> >> >> Reinout >> ------- >> >> >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Free forum by Nabble | Edit this page |