On Thu, 2003-03-20 at 10:03, Michael Bell wrote:
> We use a different behaviour. If there is something going wrong during
> initialization then we don't return the object. This is the best way to
> signal a user that new doesn't work correctly. If for example a sql
> database is not running and you call OpenCA::DBI->new then new returns
> undef to avoid any usage of the object but the user can check the
> errorcode and errormessage.
totally agreed.
> It is not a secret that it doesn't look nice but it is the most robust
> way. Would it help you if we have errval and errno package-based and
> object-based? $OpenCA::OpenSSL::errno contains the last error and
> $cryptoShell->{errno} or perhaps better $cryptoShell->errno
> contains/returns the last error of the object.
I think the two way method is a good one, but should the user be the one
to choose to ask the class or the instance, since there is a clear
dinstincion between a constructor and a instance method.
> What do you think? We are open for constructive criticism at every time.
I think the DBI approach is clean and intuitive:
- the users selects via a argument in new or via a dedicated function if
he wants errors to be displayed on stderr and if he wants the function
to return undef on error or just DIE. (RaiseError / PrintError)
- the methods call a set_err in a similar fashion as you do, and inside
it decides to die() or not and to warn() or not, of course after setting
instance and class error status.
- also there is a trace control which is similar to the debug behaviour,
but with finer control.
I think the best point is the ability to control how errors are handled,
so I can, for example, not check errors at all and let the functions
die() on me.
What do you think?
-------------------------------------------------------
This SF.net email is sponsored by: Tablet PC.
Does your code think in ink? You could win a Tablet PC.
Get a free Tablet PC hat just for playing. What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
_______________________________________________
OpenCA-Devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/openca-devel
