Raising an exception on illegal argument

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Raising an exception on illegal argument

Steffen Märcker
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
Reply | Threaded
Open this post in threaded view
|

Re: Raising an exception on illegal argument

Reinout Heeck-3
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
Reply | Threaded
Open this post in threaded view
|

Re: Raising an exception on illegal argument

Vincent Lesbros-2

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:
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


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Raising an exception on illegal argument

Steffen Märcker
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:
>>
<---Schnitt--->

>>
>> 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