-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Why does vigil punish a function that throws an unhandled exception? #9
Comments
I like the cut of your jib. Perhaps all functions above the throwing function on the stack bear the stain of culpability and should suffer the same fate. |
Maybe the entire stack should just be destroyed when an unhandled exception is thrown. Kill them all and let…someone else…sort 'em out. |
It should be written: def div(x,y): |
Presumably by reading the code, just as they would have to if implore() were used. |
Believe it or not, my dissertation covered this ground. Here's our conference paper on the subject: http://www.eecs.northwestern.edu/~robby/pubs/papers/ho-contracts-icfp2002.pdf |
I've actually read that paper! Well, it's probably more accurate to say I have that paper sitting in my folder of papers to read, but I'm at least familiar with. That counts for something, right? |
Sweet. But on second thought: just program in a little in Racket. :) Have a look at the contracts section of the Guide instead. |
It seems to me that when a function, f, throws an unhandled exception, it isn't f, but whatever functions are above f on the call stack which are WRONG and should be PUNISHED.
For example (forgive the syntax, I don't write python):
def div(x,y):
if y == 0
throw exception
else
return x/y
def bad():
return div(1,0)
def main():
return bad()
Nothing about div() is incorrect.
It is simply the victim of a bad calling context.
Isn't throwing an exception a form (albeit much less righteous) of implore()'ing constraints on input arguments?
I believe the only difference between what I'm proposing and your policy is that vigil would delete div() as well as the calling stack (recursively) as opposed to sparing div().
Couldn't you instead mutilate div() in some fashion or another?
Such as by modifying it to implore() against the input arguments which caused the exception to be thrown?
The text was updated successfully, but these errors were encountered: