ARSperl Programmer's Manual - OO Layer Overview

Objective

Features

Exception Handlers

The OO layer abstracts exception handling away a bit (optionally, ofcourse). By default, the layer installs three handlers that are called if an FATAL, ERROR, or WARNING return code is returned by the ARS C API. At first, these handlers map to the Perl "die" and "warn" functions. You can, however, disable or over-ride this feature and install your own handlers.

Have a look at the Connection Object's constructor method.

Also examine the t/entry.t script available in the source distribution for an example of how to use this.

Basically, what this means is you don't have to test the return code of each call you make. If a call encounters a problem while doing it's job, it'll call an exception handler to handle the problem.

Wide Variety of API Calls

Since the OO layer is written ontop of ARSperl itself, you can "mix and match" the two within scripts. This allows you access to all of the API calls you've come to use while allowing you to utilize some OOP practices where available. You don't need to login twice, the OO layer and the class functional layer can share a single control record.

Automatic Type Conversion

The OO layer converts enumeration values on the fly for you. This is done on creates, sets and gets. You no longer have to lookup with enumeration values yourself.

Named Parameters

All of the OO layer's methods accept named parameters so you don't have to remember what the correct parameter order is. You can optionally leave out the named parameter portion (if you like) but then you'll need to be sure you get the order right (just like in the "classic", i.e. ars_*, function calls).

Also noteworthy is that the named parameters are case-insensitive.

Parameter Checking

Finally, if you utilize Named Parameters, then the methods will check to make sure you specified the minimum number of parameters and will put up a usage message if you have not.

Stack Trace

Last, but not least, the OO layer uses the Carp module to give you a meaningful backtrace in the event of an error. Unlike the classic function call interface, and error might occur and one of several points, the traceback functionality of Carp makes it more obvious where the error is occurring in your code.