> Gathering more info about the exceptions are nice thing to do. However, it > triggers lots of unnecessary execution since they will fail the same way. It > would be nice to see the exception immediately, then correct the problem and > continue on. Of course, most of these scenarios will be happened at > development time, not in the real business runtime. The performance is not a > big issue.
How much extra time is this costing you? Compare this to compilation; I'd rather let the compiler do more work and report more problems, rather than having to go through a source file one error at a time. -Patrick On 8/23/07, Teresa Kan <[EMAIL PROTECTED]> wrote: > Patrick, > Thanks for the explanation! > Gathering more info about the exceptions are nice thing to do. However, it > triggers lots of unnecessary execution since they will fail the same way. It > would be nice to see the exception immediately, then correct the problem and > continue on. Of course, most of these scenarios will be happened at > development time, not in the real business runtime. The performance is not a > big issue. > Will it be helpful if we can provide a property to gather the exceptions as > user wants? By default, we can just throw the exception whenever it occurs. > During the development time, if user wants to gather more info, then he/she > can enable the property to see more exceptions. I don't have a strong > opinion about the default value.. Use the current behavior as default is > fine too. > Any comment? > > Thanks > Teresa > > > > > On 8/22/07, Patrick Linskey <[EMAIL PROTECTED]> wrote: > > > > > Currently I have 100 insertions, each has a constraint violation. > > > Instead of stopping the processing of the insertion once an exception > > was > > > encountered, all 100 insertions were executed. Then 100 exceptions were > > > thrown at the end of process. Will it waste the time to continue to > > execute > > > the statement once an exception occurs? > > > > The nice thing about gathering all the exceptions is that the user is > > presented with more information about what went wrong. So, you know > > that all 100 records had problems, not just one of them. > > > > Clearly, this will take additional time. However, the proverbial ship > > is sinking at this point anyways, so performance isn't really the > > concern. If a system has lots of these failures happening at the same > > time, that will be bad for the overall throughput, but that's > > definitely not the expected case. > > > > Is the exception-gathering behavior causing problems for you? > > > > -Patrick > > > > On 8/22/07, Teresa Kan <[EMAIL PROTECTED]> wrote: > > > What are the rules to handle the exception? > > > I found out that in the OperationOrderUpdateManager.flush (rowMgr, > > psMgr, > > > exceps), it always flushed all the primary rows first, then flush any > > > constraintUpdates, then the secondary rows. In each set of flush, it > > saved > > > all the exceptions. If any exception in the primary rows, should we > > rollback > > > the transaction instead of continue to the next flush? > > > I don't see the logic closely enough that will handle the exception and > > > retry if there is any constraint violation. So if one table has the > > > exception, should we throw the exception? What scenario that will cause > > the > > > first exception be ignored ? I also discovered that the exception > > eventually > > > be threw back and failed at the end. > > > > > > Currently I have 100 insertions, each has a constraint violation. > > > Instead of stopping the processing of the insertion once an exception > > was > > > encountered, all 100 insertions were executed. Then 100 exceptions were > > > thrown at the end of process. Will it waste the time to continue to > > execute > > > the statement once an exception occurs? > > > > > > Please clarify and thanks, > > > > > > Teresa > > > > > > > > > -- > > Patrick Linskey > > 202 669 5907 > > > -- Patrick Linskey 202 669 5907
