Prev | Current Page 370 | Next

L. McColl-Sylvester and F. Ponticelli

"Professional haXe and Neko"


191
Chapter 7: When Things Go Wrong
Catching Unexpected Exceptions
As a fair and well - organized programmer, you have to be sure that all exceptions thrown from your code
will be fully documented so that any other developer utilizing your code will have prepared catch
statements for every eventuality. However, there are times when an exception slips through the net
causing serious problems for the user of the application, and even more serious implications for the
developer who has just received a nasty letter describing how a user had recently lost hours of work
because of some unexplained software bug, and to expect a bill for loss of earnings. Not nice.
This sort of situation could happen to anyone (or at least those of you who haven ??™ t thought through your
software licensing), and indeed, you could argue that, had the developer used a catch statement for the
Dynamic type, thus catching all further exceptions for a try block, then this bug might not have
happened. But what if the exception was thrown from someone else ??™ s code that you yourself utilized
and was not surrounded within a try block at any point while it bubbled its way through your class
hierarchy?
Let ??™ s pause for a moment and consider this problem.


Pages:
358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382