3 ms·

> while ignoring the ridiculous notion that you can know every possible error that every function can trigger now or in the future. If you have a statically ty

by jimmy1 8y ago

> while ignoring the ridiculous notion that you can know every possible error that every function can trigger now or in the future. If you have a statically typed language, and defined error types that are only thrown in certain situations, can you please explain to me why it is so ridiculous to think you cannot know every possible error that will occur? If function a calls function b, and function b throws errors x y and z, why is it I cannot check for x y and z in function a? Additionally, say there are some additional outside runtime errors that can occur such as out of memory errors, again these are ideally known ahead of time, and you can use a constrained runtime to minimize them. Taking this a little further, if you cannot know every possible error, then you cannot possibly have any sort of remote closeness to formal verification, and that means our software systems that rely on more stringent verification methods are a lie. (I hope you don't write any medical device software!) I am making an assumption and maybe think you are just trying to say this heuristically ? Like maybe we are all writing web software, and meh, close enough if you handle most errors, and "meh" for the rest of them? I mean I certainly think that works for the majority of development that happens, but more and more we are becoming keenly aware that our software has real world impact on people's lives and maybe some added stringency is what we need.

wvenable 8y ago
You know every single error every framework function can call? Every single error in your entire code base? What about tomorrow when Bob changes some code? > If function a calls function b, and function b throws errors x y and z, why is it I cannot check for x y and z in function a? How often do you have a single function in your call stack? Do you also handle/swallow every error in every function or do you propagate those errors? So function q throws errors it was called by function p that throws and by the time you get back to a the list is a lot longer than x, y, z. Formal verification is a red herring. I know my software either handles all the errors that it can or stops processing and informs someone. Error types don't remove complexity or make humans better at error handling.

by jimmy1 8y ago

wvenable 8y ago

You know every single error every framework function can call? Every single error in your entire code base? What about tomorrow when Bob changes some code? > If function a calls function b, and function b throws errors x y and z, why is it I cannot check for x y and z in function a? How often do you have a single function in your call stack? Do you also handle/swallow every error in every function or do you propagate those errors? So function q throws errors it was called by function p that throws and by the time you get back to a the list is a lot longer than x, y, z. Formal verification is a red herring. I know my software either handles all the errors that it can or stops processing and informs someone. Error types don't remove complexity or make humans better at error handling.