3 ms·

Can someone explain this error to me simply, like one might talk to a golden retriever?

iSnow 14y ago
Somewhere in the system is a friendly program called "DataDetectors", which sniffes at text so find out if there are links in it which should be highlighted by the application handling the text. Now the programmer who developed DataDetectors wanted to make sure (maybe for tests) that a subcomponent was fed only valid file-urls (that is: file:/// is OK, File:/// not) and therefore inserted an assert-statement. Assertions stop the program flow if their condition is not met (an exception is thrown) and normally a code block upstream should handle this case. I can only speculate, but either the assertion was left in the code despite being only intended for debugging/testing (ie. it was meant to be there only temporarily) or the upstream code has a bug that causes it not to catch the exception. Either way, it is not handled and therefore bubbles up the whole code chain until some monitor in OS X or Objective C terminates the program because it sees a program error. Someone at Apple forgot a test case feeding text with File:/// to DataDetectors.
- TallboyOne 14y ago
  Thank you, iSnow! Makes perfect sense.
- martinced 14y ago
  "Someone at Apple forgot a test case feeding text with File:/// to DataDetectors." There's obviously and blatantly a combinatorial explosion of possible inputs into a textbox so it's physically impossible ("physically" as in: "there aren't enough atoms in the universe to build a machine able to handle this) to test all the possible inputs. By your logic when the terrible endless loop in the Java floating-point parsing library (you could stuck any JVM by trying to parse: 2.2250738585072012e-308) was discovered, it's because: "Someone forgot to write a test case trying to parse 2.2250738585072012e-308" Yeah. Sure.
  - iSnow 14y ago
    I am not sure why you sound so angry, but let me try to explain: Every time you build in an assertion like that you should have a test case to prove the program handles it like you intended it to. And concerning the Java FP bug: yes, someone forgot to test the corner cases of the Java FP range. You don't need to test every FP number out there, but you absolutely need the highest, lowest, highest+1, lowest+1, zero, +/-infinity, division by zero and if you are good highest +0, lowest + 0 and some conversions from and to long, int etc.
  - deleted 14y ago
    [deleted]

iSnow 14y ago

Somewhere in the system is a friendly program called "DataDetectors", which sniffes at text so find out if there are links in it which should be highlighted by the application handling the text. Now the programmer who developed DataDetectors wanted to make sure (maybe for tests) that a subcomponent was fed only valid file-urls (that is: file:/// is OK, File:/// not) and therefore inserted an assert-statement. Assertions stop the program flow if their condition is not met (an exception is thrown) and normally a code block upstream should handle this case. I can only speculate, but either the assertion was left in the code despite being only intended for debugging/testing (ie. it was meant to be there only temporarily) or the upstream code has a bug that causes it not to catch the exception. Either way, it is not handled and therefore bubbles up the whole code chain until some monitor in OS X or Objective C terminates the program because it sees a program error. Someone at Apple forgot a test case feeding text with File:/// to DataDetectors.

TallboyOne 14y ago
Thank you, iSnow! Makes perfect sense.
martinced 14y ago
"Someone at Apple forgot a test case feeding text with File:/// to DataDetectors." There's obviously and blatantly a combinatorial explosion of possible inputs into a textbox so it's physically impossible ("physically" as in: "there aren't enough atoms in the universe to build a machine able to handle this) to test all the possible inputs. By your logic when the terrible endless loop in the Java floating-point parsing library (you could stuck any JVM by trying to parse: 2.2250738585072012e-308) was discovered, it's because: "Someone forgot to write a test case trying to parse 2.2250738585072012e-308" Yeah. Sure.
- iSnow 14y ago
  I am not sure why you sound so angry, but let me try to explain: Every time you build in an assertion like that you should have a test case to prove the program handles it like you intended it to. And concerning the Java FP bug: yes, someone forgot to test the corner cases of the Java FP range. You don't need to test every FP number out there, but you absolutely need the highest, lowest, highest+1, lowest+1, zero, +/-infinity, division by zero and if you are good highest +0, lowest + 0 and some conversions from and to long, int etc.
- deleted 14y ago
  [deleted]