While performing an exploration, I encountered an error Array subscript out of range. This error caused the exploration to stop.
Is it possible to let the exploration continue running despite encountering an error on one of the symbols? I'm not sure how long the bug fix will take. So, in the mean time, I would like to allow the exploration to continue running while waiting for bug to be fixed.
This maybe a bit off topic but I was compelled to read more about it.
I was under the impression that the later so called "more popular" languages and frameworks implemented very nice Exception Handling but it actually goes way long back in time.
I have seen a lot of code, or an entire Class logic written within Try-Catch scope and wonder, "How much worse can a programmer's life be?"
Some references, just a good weekend read, I think.
At first a lot of discussions pointed to Bjarne Stroustrup and C++ back in 1979 but the above article has profound notion.
From his notes:
[A]t the Palo Alto [C++ standardization] meeting in November 1991, we heard a brilliant summary of the arguments for termination semantics backed with both personal experience and data from Jim Mitchell (from Sun, formerly from Xerox PARC). Jim had used exception handling in half a dozen languages over a period of 20 years and was an early proponent of resumption semantics as one of the main designers and implementers of Xerox's Cedar/Mesa system. His message was
“termination is preferred over resumption; this is not a matter of opinion but a matter of years of experience. Resumption is seductive, but not valid.”
He backed this statement with experience from several operating systems. The key example was Cedar/Mesa: It was written by people who liked and used resumption, but after ten years of use, there was only one use of resumption left in the half million line system – and that was a context inquiry. Because resumption wasn't actually necessary for such a context inquiry, they removed it and found a significant speed increase in that part of the system. In each and every case where resumption had been used it had – over the ten years – become a problem and a more appropriate design had replaced it. Basically, every use of resumption had represented a failure to keep separate levels of abstraction disjoint
One day we may have Try-Catch blocks in AFL too but writing great code will always be supreme and has no substitute.
Oh no, exceptions would not make your code correct. And try-catch is definitely not good idea for AFL. Just the opposite. Maybe you got exited with the "knowledge" you "just read", but before copy-pasting Stroustrup and evangelizing exceptions in order to be able to "continue" regardless of obvious errors (that can and should be fixed), I would advise to read that instead: http://awesci.com/the-astonishingly-funny-story-of-mr-mcarthur-wheeler/
Hint: the next day when try-catch is available people like Mr. Wheeler would put their code in
// faulty code
catch( ... )
// just ignore ALL errors! who cares about errors!
// I've got face covered in lemon juice so I am invisible
and then say "my code is fine as it does not show any errors but does not work. So your platform is faulty!
Like many "theoretically" good ideas added in C++, and like many other things in life, exceptions are not as easy as they look on the surface. In attempt to solve one problem it generated a whole bunch of others that are not visible to casual spectator. I have seen programmers with even 10+ years of experience that were (ab)using exceptions in all wrong ways, so it is hard to expect from beginners to know how not to use this mechanism. That is why having it would do more harm than good.
Hehe, I think you misread me.
I was just quoting some parts I read but I'm clear that the focus on writing correct and complete code is the only way to go even though the programming framework may contain exception handling as even I've seen it being abused.