Obsessed with Oracle PL/SQL

Received feedback today from James S on my latest Oracle Magazine article, Planning for Trouble . I will respond here (there is no mechanism for comments/discussion at the Oracle Magazine page). If you haven't yet read it, I suggest you do so before proceeding with this post. Comment 1.  This is regarding exception handling.  Let’s say the client calls procedure A, and A calls B, B calls C.  Are you suggesting we add a “When others” + error logging logic in each level? Does it mean one error will be logged three times? (because it is captured and re-raised each time). Good point, James. I make the argument in the article that you should trap the exception as close as possible to where it was raised, so that you can log  the  values of local variables that may help you diagnose the problem.  [Here's reinforcement of that point (and other great points about doing effective execution tracing) - they call it contextual logging:  http://www.stack...

In my November/December 2014 article for Oracle Magazine, Planning for Trouble , I urge developers to realize that regardless of best intentions, not everything related to our apps is under our control, and we need to assume that trouble might be coming our way. I received today, the following comments from Gary Malandro, which I thought you might enjoy reading: Enjoyed your article in Oracle Magazine, and I have a few comments. 1.         You mentioned “Documents that spell out naming conventions…fit very nicely inside desk drawers”.  On our team, we have a number of policies that include the requirements for a technical design document, a software change request, source control, and some regarding style.  First thought upon hearing that is probably what-a-load-of-bureaucratic-nonsense.  Well, there are reasons for creating and enforcing these standards.  Compliance for one.  Another is we had code going into producti...

Received this note today from Debbie B: I attended your Turbo Charge PL/SQL seminar today. I still have a question about where to put COMMIT. I’m using 10g. See (pseudo) code below. Say I have 50,000 records and the LIMIT is 100. If an exception is thrown: Do I need a COMMIT in the WHEN clauses so successful DML gets committed, then loop processing will continue? I  was thinking each DML needed it’s own BEGIN EXCEPTION END block so I would know if the error happened due to the insert or the update and could log the appropriate error. Is this wrong?   OPEN v_cursor;   LOOP     FETCH v_cursor BULK COLLECT INTO data_array LIMIT i_limit;     EXIT WHEN data_array.COUNT = 0;     BEGIN       FORALL i IN 1.. data_array.COUNT SAVE EXCEPTIONS         INSERT INTO some_table VALUES data_array (i);         COMMIT; ...