Re: Not using exceptions only for exceptional conditions




villo wrote:
Hi everybody

I always have agreed that exception shouldn't be used for flow control,
nevertheless I have incurred in a situation where breaking this
principle is probably good, for other reasons than design.

The situation is inserting a row in a table, extremely simple stuff. It
happens that the application is basically only doing this and the table
has ~10^7 records, so I have rewritten the application logic, that
would be correctly described as

ARecordObject r=...

if(aDao.find(r)!=null)
aDao.insert(r);
else
aDao.merge(r,anotherRecordObject);

in the form of

if(!aDao.insert(r))
aDao.merge(r,anotherRecordObject);

where insert catches DataIntegrityViolationException and returns true
iff an insert was made.

Now, I see that the first form is better for many reasons, but if the
latter performs faster should I really
bother?

Cheers
Francesco


It is absolutly bad solution. You cannot achieve reasonable performance
using second way. Exceptions are realy realy slow for building stack
trace. If you do not want to use SQL test over DB use other way to
determine which operation is required. I cant recomend DB stored
porcedures. This is hard to write and bound application to special
Database infrastructure lovering portability and cacheing abilities.

.



Relevant Pages

  • Re: InterruptedException handling
    ... call was made to sleep there were a number of reasons that it might return early that had little to do with the program being written. ... It was typical to wrap these calls in a loop so that the program would sleep for the correct amount of time. ... So when I first moved to Java I would typically do the same thing with an InterruptedException, catching it and looping back to the wait or the sleep or whatever had caused the exception. ...
    (comp.lang.java.programmer)
  • Re: Web.Mail Problems
    ... I had a similar cdo problem and solved ... On Google there are dozens of articles that can be ... > found on different possible reasons for this error. ... >> Catch ex As Exception ...
    (microsoft.public.dotnet.languages.vb)
  • Re: A call for a moderated AUE (was: Re: OT Pounds)
    ... It worked amazingly well for two reasons: One, without exception, ... but they were all on board; two, the only form that moderation takes is ... the prohibition, implemented by a robo-moderator, of crossposted ...
    (alt.usage.english)
  • Re: Managed DirectX9, RenderToTexture fails
    ... > DeviceLost may be caused by several reasons. ... statement is inside a try/catch block, but the exception was _not_ caught ... SDK, and now that I think of it, that may be what's causing the different ... change my DX9/2003-based code so it compiles ...
    (microsoft.public.win32.programmer.directx.video)
  • Re: Housekeeping in application with VS2005 squiggles!
    ... The only real standard is to throw an exception if the data layer was unable ... Of course there are reasons to sometimes go for ... Dim Connection As SQLConnection = Nothing ... they have been successful or not (lets say an update database function ...
    (microsoft.public.dotnet.framework.aspnet)