Of course, writing and running unit tests is really only part of the whole testing process.
You still need to actually evaluate the results of the tests you run, and to do that, you need to
have a thorough understanding of Active Record exceptions. So let??™s turn our focus to those
now.
Active Record Errors and Exceptions
Working with a database means adding at least one additional layer of application complexity,
and each layer of complexity, of course, means more potential for errors and exceptions to occur.
Sadly, when it comes to having to deal with errors and exceptions Active Record is, uh, no
exception (sorry about the horrible pun).
Since Ruby is a pure object-based language, the approach that Active Record wisely took
with exception handling was to simply use inheritance, so all of the default error classes that
Active Record defines inherit from the general ActiveRecordError class. The ActiveRecordError
class itself inherits from Ruby??™s StandardError class. All of this basically means that Active Record
errors and exceptions are simply handled in the same way any other Ruby error is; that is, they
can be raised by a raise clause and caught by a rescue clause.
Pages:
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333