C# Error handling

[aaj]

Hi all

I have an automated application, that runs in the middle of the night.

If certain 'non system' errors occur (things like malformed files, missing
files etc..), I send an automatic Email and write a record to the database.
This is handled in a class.

When these errors occur, once Emailed and written I want to just end the
App, simple as that.

My inital thought was to End the Application at the end of the error
handling class using Application.Exit or Environment Exit. this means I just
write the code once and thats it, the App stops dead!! But while reading up,
It seems to be bad practice.

Is a better way to set a flag within the Error handling class, work its way
up the chain and then exit in the form code. The only problem is, some of
the error handling is nested quite deeply and passing this back to the top
level form may get a bit messy.

Does anyone have any recommendations for best practices on dealing with this
type of error handling.

many thanks.

Andy

[Adam]

You could define a custom exception that is thrown whenever this case
arises. The code at the highest level catches the exception and
performs the procedures to shut down.

[Nick Malik [Microsoft]]

You made two statements that are interesting in combination:

I have an automated application, that runs in the middle of the night. /and/ Is a better way to set a flag within the Error handling class, work its
way
up the chain and then exit in the form code.
So this is a windows forms application that runs in the middle of the night.

Not knowing your code, I'm going to _guess_ that you have combined the logic
of the GUI with the business logic that can run "in the middle of the
night".
And this is where your problem lies.

I would suggest that the best option is to take your app and split it. One
side is the GUI and the other side is the "business layer" that has all the
code for doing the fundamental work, but has NO interface code in it.

Then, make a new EXE that is a console application. This EXE will be the
one that runs in the middle of the night, or runs as a service, or runs from
the windows scheduler, or runs on a server, or any of the other automated
needs that are likely to arise. This EXE will start, look at the local
environment, (perhaps get data from a settings file or command line
parameters), and check for errors in the data. If errors are found, you
have no code to unwind. You stop from the caller.

If there are no errors, then you proceed.

This is not a new situation. I've seen it re-enacted repeatedly for years.
The solution is the same, whether you use COM or .Net or even C dlls.
Seperate the business from the interface and use a new interface for the
automated work.

Good Luck,

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
"aaj" <aa*@aaj.com> wrote in message
news:1117630892.5d1cb1393192df959e430d0640ff53f3@t eranews... Hi all

I have an automated application, that runs in the middle of the night.

If certain 'non system' errors occur (things like malformed files, missing
files etc..), I send an automatic Email and write a record to the
database.
This is handled in a class.

When these errors occur, once Emailed and written I want to just end the
App, simple as that.

My inital thought was to End the Application at the end of the error
handling class using Application.Exit or Environment Exit. this means I
just
write the code once and thats it, the App stops dead!! But while reading
up,
It seems to be bad practice.

Is a better way to set a flag within the Error handling class, work its
way
up the chain and then exit in the form code. The only problem is, some of
the error handling is nested quite deeply and passing this back to the top
level form may get a bit messy.

Does anyone have any recommendations for best practices on dealing with
this
type of error handling.

many thanks.

Andy

[aaj]

Thanks guys

Nick, your quite correct, to give a bit of background, the GUI was just a
hang on from before the days when the code was automated (it runs as a
scheduled task now, and because of the Email and database logging doesn't
need any GUI, I just couldn't see the wood for the trees 8-)

that said though, both solutions seem to suggest handling the the errors and
passing them back up through the chain and exiting the App in its natural
place....

What I'm trying to ask (but not very well)... is if I have a class that
utilises another class, which inturn utilises another series of classes, and
one of the grandchild classes detects that something is wrong (not a system
fault, but some thing which is semi predictable) is it acceptable (good/bad
practice) to terminate the application right there in the grandchild class
(as there is no need for any more work to be done by the app, nothing has
been written yet, so no rewinding necessary etc..)

or

should the fact that a problem has been detected be passed all the way up
the chain to the control class where the rest of the code can be skipped in
a controlled manner and let the program terminate in its normal way.

Just as a bit of extra info, the reason I don't do all the checks before
proceeding with the importing of the data is purely down to efficiency.
Because the data is correct 98% of the time, I validate the data as it
streams in, rather than testing it and then streaming it in, and if
anomilies that should stop the import occur.

many thanks again, and I hope the above make sense

Andy

"aaj" <aa*@aaj.com> wrote in message
news:1117630892.5d1cb1393192df959e430d0640ff53f3@t eranews...

Hi all

I have an automated application, that runs in the middle of the night.

If certain 'non system' errors occur (things like malformed files, missing
files etc..), I send an automatic Email and write a record to the
database.
This is handled in a class.

When these errors occur, once Emailed and written I want to just end the
App, simple as that.

My inital thought was to End the Application at the end of the error
handling class using Application.Exit or Environment Exit. this means I
just
write the code once and thats it, the App stops dead!! But while reading
up,
It seems to be bad practice.

Is a better way to set a flag within the Error handling class, work its
way
up the chain and then exit in the form code. The only problem is, some of
the error handling is nested quite deeply and passing this back to the top
level form may get a bit messy.

Does anyone have any recommendations for best practices on dealing with
this
type of error handling.

many thanks.

Andy

[Nick Malik [Microsoft]]

My personal opinion is that doing the latter makes for more readable and
flexible code.

There is no hard and fast rule. Using a custom exception that you catch at
the top level is one mechanism you may want to look at.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
"aaj" <aa*@aaj.com> wrote in message
news:1117700217.56b280d8f3fd4f1d5c4bb10d66a84d08@t eranews...

Thanks guys

Nick, your quite correct, to give a bit of background, the GUI was just a
hang on from before the days when the code was automated (it runs as a
scheduled task now, and because of the Email and database logging doesn't
need any GUI, I just couldn't see the wood for the trees 8-)

that said though, both solutions seem to suggest handling the the errors
and passing them back up through the chain and exiting the App in its
natural place....

What I'm trying to ask (but not very well)... is if I have a class that
utilises another class, which inturn utilises another series of classes,
and one of the grandchild classes detects that something is wrong (not a
system fault, but some thing which is semi predictable) is it acceptable
(good/bad practice) to terminate the application right there in the
grandchild class (as there is no need for any more work to be done by the
app, nothing has been written yet, so no rewinding necessary etc..)

or

should the fact that a problem has been detected be passed all the way up
the chain to the control class where the rest of the code can be skipped
in a controlled manner and let the program terminate in its normal way.

Just as a bit of extra info, the reason I don't do all the checks before
proceeding with the importing of the data is purely down to efficiency.
Because the data is correct 98% of the time, I validate the data as it
streams in, rather than testing it and then streaming it in, and if
anomilies that should stop the import occur.

many thanks again, and I hope the above make sense

Andy

"aaj" <aa*@aaj.com> wrote in message
news:1117630892.5d1cb1393192df959e430d0640ff53f3@t eranews...

Hi all

I have an automated application, that runs in the middle of the night.

If certain 'non system' errors occur (things like malformed files,
missing
files etc..), I send an automatic Email and write a record to the
database.
This is handled in a class.

When these errors occur, once Emailed and written I want to just end the
App, simple as that.

My inital thought was to End the Application at the end of the error
handling class using Application.Exit or Environment Exit. this means I
just
write the code once and thats it, the App stops dead!! But while reading
up,
It seems to be bad practice.

Is a better way to set a flag within the Error handling class, work its
way
up the chain and then exit in the form code. The only problem is, some of
the error handling is nested quite deeply and passing this back to the
top
level form may get a bit messy.

Does anyone have any recommendations for best practices on dealing with
this
type of error handling.

many thanks.

Andy