in reply to How to say 'oops' in OOPs?

I would say that a lot depends on how OO your system is.

A completely OO system would tend towards throwing and catching Error objects. Perl5 doesn't explicitly support this (but it can be done - q.v. Error for one way to do it).

If you're using objects to encapsulate logic within a procedural system, I would go ahead and do something like what DBI does - return undef to indicate failure and set an error string method (called errstr in DBI). However, this requires a consistent API across all of your objects (because you don't want some doing one thing and others doing another).

The procedural way to do it (like C) is to return 0 on success and some number on failure, that number being used to look up some error string. (This is also similar to the way eval uses $@.)

Pick your poison, I guess.

Update: As per Abigail-II, I stand corrected.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

Replies are listed 'Best First'.
Re: How to say 'oops' in OOPs?
by Abigail-II (Bishop) on Apr 08, 2003 at 14:55 UTC
    Actually, C tends to return -1 on failure, setting errno. For functions returning pointers, a NULL return value is often used to indicate failure.

    Abigail

Re^2: How to say 'oops' in OOPs?
by adrianh (Chancellor) on Apr 09, 2003 at 10:46 UTC
    I would say that a lot depends on how OO your system is.

    Exception throwing vs. returning error values is a separate issue from whether your system is OO or not. You can have non-OO systems that throw exceptions. You can have OO systems that return error objects.