terminating multiple try/catches

[darrel]

Not quite sure how to word this.

I have a button click function that calls two different subs. One updates a
database, the other writes to a file.

Both of the subs have a try/catch within them. I'd like to have both of them
execute if they can, but if one can't, then have neither execute. Is there a
way to do this that isn't too complex? I assume I'd need to first call them
and have then run-through on a 'trial run' and if succeed, return a value.
If both are returned as 'doable' then call them both again for the actual
execution.

In this particular case, one is dependant on the other but not vice versa,
so I can simply call the first one, and then call the second one if the
first one executes. But, in the future, I could see wanting two separate
functions both being dependant on each other. Or is that bad design?

-Darrel

[John Timney \(ASP.NET MVP\)]

why cant one simpley execute after the other, write the file first - if it
succeeds then write to DB, if that fails delete file in catch.

You could always trap your write event failure code in your catch for file
write and evaluate it in your db execute, with clean up in the finally
clause of DB execute.

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director

"darrel" <no*****@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...

Not quite sure how to word this.

I have a button click function that calls two different subs. One updates a database, the other writes to a file.

Both of the subs have a try/catch within them. I'd like to have both of them execute if they can, but if one can't, then have neither execute. Is there a way to do this that isn't too complex? I assume I'd need to first call them and have then run-through on a 'trial run' and if succeed, return a value.
If both are returned as 'doable' then call them both again for the actual
execution.

In this particular case, one is dependant on the other but not vice versa,
so I can simply call the first one, and then call the second one if the
first one executes. But, in the future, I could see wanting two separate
functions both being dependant on each other. Or is that bad design?

-Darrel

[darrel]

> why cant one simpley execute after the other, write the file first - if it

succeeds then write to DB, if that fails delete file in catch.

It can. Like I said, in this case, it's not a big deal, but I can see a need
where I may need both to execute and not always in the same order. (I admit,
I'm speaking in hyptheticals here.)

-Darrel

[John Timney \(ASP.NET MVP\)]

Well as they are technically serpeate subs, you would need a way of marking
them as having failed. With DB you should ideally be using transactions and
rollbacks, so your finally or catch event could evaluate success and commit
or not - it really depends on many different factors but hypothetically its
achieveable with a simple static/session variables acting as success/failure
markers or evqluating getlasterror which you could throw and evaluate on
entering any of the subs.

http://msdn.microsoft.com/library/de...errortopic.asp

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director

"darrel" <no*****@hotmail.com> wrote in message
news:uJ**************@TK2MSFTNGP14.phx.gbl...

why cant one simpley execute after the other, write the file first - if it succeeds then write to DB, if that fails delete file in catch.
It can. Like I said, in this case, it's not a big deal, but I can see a

need where I may need both to execute and not always in the same order. (I admit, I'm speaking in hyptheticals here.)

-Darrel

[darrel]

Thanks, John.

Again, this is more just for discussion than anything specific. I'll take a
look at that link and tuck it away in the back of my head if/when I ever
need it. ;o)

-Darrel

"John Timney (ASP.NET MVP)" <ti*****@despammed.com> wrote in message
news:OI**************@TK2MSFTNGP15.phx.gbl...

Well as they are technically serpeate subs, you would need a way of marking them as having failed. With DB you should ideally be using transactions and rollbacks, so your finally or catch event could evaluate success and commit or not - it really depends on many different factors but hypothetically its achieveable with a simple static/session variables acting as success/failure markers or evqluating getlasterror which you could throw and evaluate on
entering any of the subs.

http://msdn.microsoft.com/library/de...errortopic.asp
--

[jasonkester]

darrel wrote:

I have a button click function that calls two different subs. One updates a database, the other writes to a file.

Both of the subs have a try/catch within them. I'd like to have both of them execute if they can, but if one can't, then have neither execute. Is there a way to do this that isn't too complex? I assume I'd need to first call them and have then run-through on a 'trial run' and if succeed, return a value. If both are returned as 'doable' then call them both again for the actual execution.

In this specific case, could you wrap the Database operation in a
transaction, and have the first sub return a success code?

if (firstthing())
{
secondthing();
}

bool firstthing()
{
using (trans = new SqlTransaction()...)
{
try
{
insertOrWhatever();
trans.Commit();
}
catch
{
return false;
}
}

return true;
}
This would seem to work. If your database manipulation fails, your
transaction will rollback and you'll know not to try writing to the
filesystem.

Jason Kester
Expat Software Consulting Services
http://www.expatsoftware.com/

[Eric Newton]

aren't you getting that functionality? if you remove the trycatch in the
first sub, delegate the trycatch to the caller, and then if sub1 fails, sub2
never runs.

thats the KISS answer...

--
Eric Newton
eric.at.ensoft-software.com
www.ensoft-software.com
C#/ASP.net Solutions developer

"darrel" <no*****@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...

Not quite sure how to word this.

I have a button click function that calls two different subs. One updates
a
database, the other writes to a file.

Both of the subs have a try/catch within them. I'd like to have both of
them
execute if they can, but if one can't, then have neither execute. Is there
a
way to do this that isn't too complex? I assume I'd need to first call
them
and have then run-through on a 'trial run' and if succeed, return a value.
If both are returned as 'doable' then call them both again for the actual
execution.

In this particular case, one is dependant on the other but not vice versa,
so I can simply call the first one, and then call the second one if the
first one executes. But, in the future, I could see wanting two separate
functions both being dependant on each other. Or is that bad design?

-Darrel