What's the best way to minimize the need of run time checks?

[Juan Pablo Romero Méndez]

2016-08-09 14:01 GMT-07:00 Michael Selik <michael.selik at gmail.com>:

> On Tue, Aug 9, 2016 at 3:22 PM Juan Pablo Romero Méndez <
> jpablo.romero at gmail.com> wrote:
>
>> I'm actually looking for ways to minimize run time errors, so that would
>> include TypeError and AttributeError.
>>
>> In your "File-like" example having type information would prevent me from
>> even passing the wrong object, so I don't need to test for that particular
>> problem.
>>
>
> Let's clarify this discussion by using the word "check" for type-checks
> that necessary for the application to behave as desired and using the word
> "test" for checking application behavior under normal and edge cases, such
> as unexpected types being passed.
>
> Are you saying you want to minimize type-checks during the execution of
> your application? Or do you want to minimize the amount of testing code you
> write?
>


My goal is determine if there is a style of writing code in a dynamic
language that minimizes the occurrence of runtime errors AND avoids two
things:

1) using runtime checks all over the place (either ad hoc or using tools
like Valideer)
2) attempting to test for things that a type checker would normally do
 (not that this is completely possible anyway)

(I'm not suggesting I want to avoid writing tests at all, since there are
many things the type checker can't possible check).



>
> I don't check for file-likeness in the application code. If somehow a
> non-file-like (file-unlike?) object makes its way into my function, I
> expect (and hope) my program will immediately stop and print a nice
> traceback for me. If I wanted some other behavior, I probably would already
> have try/except surrounding the appropriate section to deal with not-found
> or permissions errors. If I need to, I'll add TypeError and AttributeError
> to that except statement.
>
>
This is interesting. You are Ok having runtime errors?



> I sometimes write tests for unexpected inputs, checking to ensure that
> either a TypeError or AttributeError is raised. However, sometimes I'm not
> worried about it. If the user gives me bizarre input, they should know to
> expect (possibly) bizarre results. Who knows, maybe that's what they wanted.
>
> I would add type-checking or value-checking to my application if the
> wrong type or value does not raise an error but instead causes an infinite
> loop or corrupts data. Those situations are fairly rare.
>
>
>
> On Tue, Aug 9, 2016 at 4:52 PM Juan Pablo Romero Méndez <
> jpablo.romero at gmail.com> wrote:
>
>> So as the writer of the function you expect the user to read the function
>> body to determine what is safe to pass or not?
>
>
> No. But I usually expect them to not freak out when they see a traceback.
> Or if they do freak out, I want them to freak out and send a bug report.
>