[RFC] remove RaiseError and PrintError

[abraxxa]

[RFC] remove RaiseError and PrintError

[moritz]

👍 to removing both, and just throwing an exception.

Maybe in the long run, we'll want something like a notification system (for errors and other events), but that feels like premature optimization so far.

[asb-capfan]

I tought having the raiserror option would be a good thing as it allows to continue with the program until the programmer decides to handle errors (e.g. log something first).

[pmichaud]

A thought from an outside observer: "allows to continue with the program ..." sounds a lot like a Failure object to me. Whatever gets decided should probably follow Perl 6's error handling model and not carry forward Perl 5's.

[mjegh]

I always set PrintError false and RaiseError true. Why would I want to test every DBI call.

[moritz]

@abraxxa are you going to supply a patch?

[abraxxa]

I plan that for after the merge of DBDish::Oracle.

[uberbaud]

I'm guessing that the final replacement in the user's code would be something like

use fatal; # replaces RaiseError => 1
...
# replace PrintError => 1
CATCH { when (DBIish::Exception) { .say; .resume; } }

And that works fine, so long as DBIish.pm6 contains something like

class DBIish::Exception is Exception {}

And DBDish.pm6 contains it's own

DBDish::Exception is DBIish::Exception

from which the actual drivers could inherit or just use outright. DBIish must define an Exception class so the user can reference it in and DBDish.pm must also define an Exception class which inherits from DBIish::Exception so the individual Drivers can inherit from them, or the individual drivers must use DBIish;. Both cases seem to me to be a bit of a code smell indicating that the distinction between DBIish and DBDish aren't really reflecting the real world.

So my question is, does there really need to be a separation of DBIish and DBDish, or is that, like the RaiseError/PrintError issue the result of a desire to mimic the perl 5 DBI?

[jonathanstowe]

I'd say at some point the individual drivers do need to be separated, it's alright with three or four databases but with possibly tens of them (I stopped counting the P5 DBD modules at thirty,) it would become a nightmare of maintenance, plus a barrier to further contribution of drivers.

[uberbaud]

I'm sorry, I wasn't at all clear about what I meant. Currently there is a DBIish.pm6 and a DBDish.pm6 (though there isn't an actual perl 5 DBD.pm), and it seems to me that DBDish.pm6 could be folded into DBIish.pm6, and possibly a DBDish.pod if necessary.

I'm guessing that the perl5 DBI/DBD namespace separation was to reserve the DBI namespace entirely for bits and pieces maintained by the DBI folk, while DBD was set aside for stuff that wasn't. And other than the perl6 DBDish.pm that could easily be the case with DBIish/DBDish.

[azawawi]

@abraxxa any update on DBDish::Oracle?

👍 for throwing exceptions implicitly.

[abraxxa]

I've got it working with the 2015.11 release but a bug in the 6.c release (RT#127001) prevents it from functioning with it. All code is at my github fork.

[salortiz]

The current state of affairs about error handling:

• Oracle: Simply die on errors inside the driver. The caller needs a CATCH block.
• All others: die if RaiseError is True, otherwise the errors are ignored even inside the drivers!!!

The methods for error reporting at DBIsh, DBDish's driver level and Connection level ($dbh) are no-ops.

Only at the StatementHandler level ($sth) the user can call the .errstr method to fetch the last error message.

I plan to use and generate X::DBIish::* typed Exception to throw or fail depending on RaiseError or the pragma.

I would like to preserve RaiseError for fine-grained user cases, for example at the prepared statement level.

[salortiz]

Now DBIish follow Perl 6's model regards exception handling, any additional details can be discussed as subsequent issues.

[jonathanstowe]

👍

[abraxxa]

I still don't see the point why DBIish should follow any stupid Perl 6 DBI API decisions...
Keeping the last exception in an attribute instead of just throwing it makes no sense and will lead to weird bugs and maybe even memory leaks due to circular refs.

[salortiz]

@abraxxa , We are not here to judge established API decisions, our work is to satisfy users expectations, the more of them, the better.
As documented somewhere else, the Exception throwned we keep for the benefit of the $h.err and $.errstr APIs, is short-lived and replaced (or erased) at the following API call.
If the current implementation, or its current defaults, causes to you or your applications, some issues, please open an specific cause.
(Personally I would have preferred .fail over .trow as default, i.e RaiseErrors => False)