when to catch an exception...

[Dan Bass]

In a somewhat complex application, I've developed plug-in architecture and
am having a problem as to when to catch general exceptions for logging
purposes.

In each plug-in class library, for example, I'm assuming it's throw on
errors, and that the core then catches them. I've got proxy classes handling
some fiddly details of the plug-ins.

Should I allow the exception to bubble to the top most point it can in a
call stack, then catch it and log the details, or should I do it lower down
(in the proxy for example) so that the highest level has no catch statements
because all the methods it calls are handle them?

Any suggestions or documentation on this sort of exception handling would be
much appreciated.

Thanks,

Daniel.

 

[Nicholas Paldino [.NET/C# MVP]]

Dan,

Personally, I prefer the former statement, where you let the exception
bubble to the top most point it can, and catch it there. Exceptions are
meant as an indicator when something happens which generally should not have
happened (for one reason or another). This does mean that one has to be
more diligent though in their code. For example, if trying to access a
file, you should never have an exception thrown because it doesn't exist,
because you should be checking for the existence of the file before you open
it.

However, with a plug in architecture, I would say that you would want to
wrap the calls to the plug-ins in try/catch blocks, because there is a very
defined boundary there between what is in your control, and what is out of
your control. As a matter of fact, I think this is probably a good
guideline in general (it works for me =) ).

Hope this helps.

 

[Manohar Kamath]

Dan,

This is widely debated topic -- I have seen both sides. The one thing I am
following now is, catch an exception in the layer that has a public
interface -- in Windows app this is the UI layer, in a web service it is the
web method, and in case of a web app it is the ASP.NET page. If you plan to
treat an exception as a non-exception, you can still do this in other layers
e.g. you trap an exception and reset the data accordingly, and not let the
outside world know about it.

 

[Dan Bass]

Nicholas,

Thanks for your reply.

In the case of a windows service, where a file doesn't exist as a part of
some configuration within a plugin for example, then isn't the best way to
pass this information back to the core through an exception? More so given
the code cannot continue past this point, and no alternatives exist...

Because it's a silent application in terms of user feedback, I'm struggling
a little to see the line between good old error checking and exceptions. If
there's something wrong, then I want a logger I've got to report this. It
seems the most logical way to do this is to have the catches setup at a high
level logging the error.

I think the main difference is the line is moving as to what contributes to
a fatal error. If a user's filling out a form for example, the error
checking insures they've entered everything correctly before proceeding. If
configuration on the service is incorrect, then it cannot run until
someone's fixed the configuration, and restarted the service, meaning that
all assumption inconsistencies become fatal.

Thanks.

Daniel.

Personally, I prefer the former statement, where you let the exception
bubble to the top most point it can, and catch it there. Exceptions are
meant as an indicator when something happens which generally should not
have happened (for one reason or another). This does mean that one has to
be more diligent though in their code. For example, if trying to access a
file, you should never have an exception thrown because it doesn't exist,
because you should be checking for the existence of the file before you
open it.

However, with a plug in architecture, I would say that you would want
to wrap the calls to the plug-ins in try/catch blocks, because there is a
very defined boundary there between what is in your control, and what is
out of your control. As a matter of fact, I think this is probably a good
guideline in general (it works for me =) ).

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

In a somewhat complex application, I've developed plug-in architecture
and am having a problem as to when to catch general exceptions for
logging purposes.

In each plug-in class library, for example, I'm assuming it's throw on
errors, and that the core then catches them. I've got proxy classes
handling some fiddly details of the plug-ins.

Should I allow the exception to bubble to the top most point it can in a
call stack, then catch it and log the details, or should I do it lower
down (in the proxy for example) so that the highest level has no catch
statements because all the methods it calls are handle them?

Any suggestions or documentation on this sort of exception handling would
be much appreciated.

Thanks,

Daniel.

 

[Nicholas Paldino [.NET/C# MVP]]

Dan,

In the case of a service, what I said before still stands. With a plug
in architecture, you have two boundaries. The first is the boundary between
the service and the SCM (rather your code and the runtime, and then the
SCM), and your code and the plug ins.

For a service, when you can't run because something is not configured,
you will see immediately that there is an error because the service won't
start.

However, with the plug ins, I don't think that if there is a failure in
the plug in, that constitutes a fatal error. The assumption here is that
you have more than one plug in, so failure of one shouldn't mean failure of
all of them. If one of them fails (which you detect in your exception
handling around the calls to the plug in) then you should remove it from the
list of valid plug ins, and log that event somewhere (that there was a
failure, and the plug in was removed). You then go on to run the rest of
the plug ins.

If you have only one plug in, then you have a justification for the
architecture to begin with (you do, right?), and see a need for it. Just
because if one fails doesn't mean the service should shut down, just rather,
that all of the plug ins failed. The service should continue running. Just
log the error, and continue.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Nicholas,

Thanks for your reply.

In the case of a windows service, where a file doesn't exist as a part of
some configuration within a plugin for example, then isn't the best way to
pass this information back to the core through an exception? More so given
the code cannot continue past this point, and no alternatives exist...

Because it's a silent application in terms of user feedback, I'm
struggling a little to see the line between good old error checking and
exceptions. If there's something wrong, then I want a logger I've got to
report this. It seems the most logical way to do this is to have the
catches setup at a high level logging the error.

I think the main difference is the line is moving as to what contributes
to a fatal error. If a user's filling out a form for example, the error
checking insures they've entered everything correctly before proceeding.
If configuration on the service is incorrect, then it cannot run until
someone's fixed the configuration, and restarted the service, meaning that
all assumption inconsistencies become fatal.

Thanks.

Daniel.

Personally, I prefer the former statement, where you let the exception
bubble to the top most point it can, and catch it there. Exceptions are
meant as an indicator when something happens which generally should not
have happened (for one reason or another). This does mean that one has
to be more diligent though in their code. For example, if trying to
access a file, you should never have an exception thrown because it
doesn't exist, because you should be checking for the existence of the
file before you open it.

However, with a plug in architecture, I would say that you would want
to wrap the calls to the plug-ins in try/catch blocks, because there is a
very defined boundary there between what is in your control, and what is
out of your control. As a matter of fact, I think this is probably a
good guideline in general (it works for me =) ).

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

In a somewhat complex application, I've developed plug-in architecture
and am having a problem as to when to catch general exceptions for
logging purposes.

In each plug-in class library, for example, I'm assuming it's throw on
errors, and that the core then catches them. I've got proxy classes
handling some fiddly details of the plug-ins.

Should I allow the exception to bubble to the top most point it can in a
call stack, then catch it and log the details, or should I do it lower
down (in the proxy for example) so that the highest level has no catch
statements because all the methods it calls are handle them?

Any suggestions or documentation on this sort of exception handling
would be much appreciated.

Thanks,

Daniel.

 

[Dan Bass]

Nicholas,

Thanks, you've helped make things a lot clearer. I need to clean up my
terminology too... ;o)

Daniel.

Dan,

In the case of a service, what I said before still stands. With a plug
in architecture, you have two boundaries. The first is the boundary
between the service and the SCM (rather your code and the runtime, and
then the SCM), and your code and the plug ins.

For a service, when you can't run because something is not configured,
you will see immediately that there is an error because the service won't
start.

However, with the plug ins, I don't think that if there is a failure in
the plug in, that constitutes a fatal error. The assumption here is that
you have more than one plug in, so failure of one shouldn't mean failure
of all of them. If one of them fails (which you detect in your exception
handling around the calls to the plug in) then you should remove it from
the list of valid plug ins, and log that event somewhere (that there was a
failure, and the plug in was removed). You then go on to run the rest of
the plug ins.

If you have only one plug in, then you have a justification for the
architecture to begin with (you do, right?), and see a need for it. Just
because if one fails doesn't mean the service should shut down, just
rather, that all of the plug ins failed. The service should continue
running. Just log the error, and continue.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Nicholas,

Thanks for your reply.

In the case of a windows service, where a file doesn't exist as a part of
some configuration within a plugin for example, then isn't the best way
to pass this information back to the core through an exception? More so
given the code cannot continue past this point, and no alternatives
exist...

Because it's a silent application in terms of user feedback, I'm
struggling a little to see the line between good old error checking and
exceptions. If there's something wrong, then I want a logger I've got to
report this. It seems the most logical way to do this is to have the
catches setup at a high level logging the error.

I think the main difference is the line is moving as to what contributes
to a fatal error. If a user's filling out a form for example, the error
checking insures they've entered everything correctly before proceeding.
If configuration on the service is incorrect, then it cannot run until
someone's fixed the configuration, and restarted the service, meaning
that all assumption inconsistencies become fatal.

Thanks.

Daniel.

Personally, I prefer the former statement, where you let the
exception bubble to the top most point it can, and catch it there.
Exceptions are meant as an indicator when something happens which
generally should not have happened (for one reason or another). This
does mean that one has to be more diligent though in their code. For
example, if trying to access a file, you should never have an exception
thrown because it doesn't exist, because you should be checking for the
existence of the file before you open it.

However, with a plug in architecture, I would say that you would want
to wrap the calls to the plug-ins in try/catch blocks, because there is
a very defined boundary there between what is in your control, and what
is out of your control. As a matter of fact, I think this is probably a
good guideline in general (it works for me =) ).

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

"Dan Bass" <danielbass [at] postmaster [dot] co [dot] uk> wrote in
message
In a somewhat complex application, I've developed plug-in architecture
and am having a problem as to when to catch general exceptions for
logging purposes.

In each plug-in class library, for example, I'm assuming it's throw on
errors, and that the core then catches them. I've got proxy classes
handling some fiddly details of the plug-ins.

Should I allow the exception to bubble to the top most point it can in
a call stack, then catch it and log the details, or should I do it
lower down (in the proxy for example) so that the highest level has no
catch statements because all the methods it calls are handle them?

Any suggestions or documentation on this sort of exception handling
would be much appreciated.

Thanks,

Daniel.

 

[Dan Bass]

Thanks for your reply and help. =o)

Dan,

This is widely debated topic -- I have seen both sides. The one thing I am
following now is, catch an exception in the layer that has a public
interface -- in Windows app this is the UI layer, in a web service it is
the
web method, and in case of a web app it is the ASP.NET page. If you plan
to
treat an exception as a non-exception, you can still do this in other
layers
e.g. you trap an exception and reset the data accordingly, and not let the
outside world know about it.

 

[Dan Bass]

Nicholas,

I've been working along these lines in modifying the application and have
come up with this...

One use of the plug-in's is to send and receive data from various sources.
One of these happens to be using database connections. In this case, should
I catch the exception at this level, and call "Close" on the connection
before rethrowing the exception after "tidying" up?

If I don't and there's a timeout, or stored procedure error say, does this
close the connection to the database?
If it doesn't what happens when I try to create a new connection to the same
database again? Presumably this will utilise the connection pool and reuse
the connection I had before. Would a "new" on this connection close the old
one before creating the new one?

I've got the code below... Most of the project is in C#, but some is in VB,
this happens to be the latter...

Public Overrides Sub CompleteReceive()

' open the database

Dim dbData As OdbcConnection = New OdbcConnection
dbData.ConnectionString = connectionString
dbData.Open()


' call the header update to set the record to "processed"

Dim dbcommand As OdbcCommand = New OdbcCommand
dbcommand.Connection = dbData
dbcommand.CommandText = "{Call " & inHeaderUpdateproc & " (?, ?,
?)}"
dbcommand.CommandType = CommandType.StoredProcedure
dbcommand.Parameters.Add("@MsgNumber",
NullToBlank(currentMsgNumber))
dbcommand.Parameters.Add("@Status", "PROCESSED")
dbcommand.Parameters.Add("@Size", -1)
dbcommand.ExecuteNonQuery()

dbData.Close()

End Sub


Thanks again for your feedback and help on this.

Dan,

In the case of a service, what I said before still stands. With a plug
in architecture, you have two boundaries. The first is the boundary
between the service and the SCM (rather your code and the runtime, and
then the SCM), and your code and the plug ins.

For a service, when you can't run because something is not configured,
you will see immediately that there is an error because the service won't
start.

However, with the plug ins, I don't think that if there is a failure in
the plug in, that constitutes a fatal error. The assumption here is that
you have more than one plug in, so failure of one shouldn't mean failure
of all of them. If one of them fails (which you detect in your exception
handling around the calls to the plug in) then you should remove it from
the list of valid plug ins, and log that event somewhere (that there was a
failure, and the plug in was removed). You then go on to run the rest of
the plug ins.

If you have only one plug in, then you have a justification for the
architecture to begin with (you do, right?), and see a need for it. Just
because if one fails doesn't mean the service should shut down, just
rather, that all of the plug ins failed. The service should continue
running. Just log the error, and continue.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Nicholas,

Thanks for your reply.

In the case of a windows service, where a file doesn't exist as a part of
some configuration within a plugin for example, then isn't the best way
to pass this information back to the core through an exception? More so
given the code cannot continue past this point, and no alternatives
exist...

Because it's a silent application in terms of user feedback, I'm
struggling a little to see the line between good old error checking and
exceptions. If there's something wrong, then I want a logger I've got to
report this. It seems the most logical way to do this is to have the
catches setup at a high level logging the error.

I think the main difference is the line is moving as to what contributes
to a fatal error. If a user's filling out a form for example, the error
checking insures they've entered everything correctly before proceeding.
If configuration on the service is incorrect, then it cannot run until
someone's fixed the configuration, and restarted the service, meaning
that all assumption inconsistencies become fatal.

Thanks.

Daniel.

Personally, I prefer the former statement, where you let the
exception bubble to the top most point it can, and catch it there.
Exceptions are meant as an indicator when something happens which
generally should not have happened (for one reason or another). This
does mean that one has to be more diligent though in their code. For
example, if trying to access a file, you should never have an exception
thrown because it doesn't exist, because you should be checking for the
existence of the file before you open it.

However, with a plug in architecture, I would say that you would want
to wrap the calls to the plug-ins in try/catch blocks, because there is
a very defined boundary there between what is in your control, and what
is out of your control. As a matter of fact, I think this is probably a
good guideline in general (it works for me =) ).

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

"Dan Bass" <danielbass [at] postmaster [dot] co [dot] uk> wrote in
message
In a somewhat complex application, I've developed plug-in architecture
and am having a problem as to when to catch general exceptions for
logging purposes.

In each plug-in class library, for example, I'm assuming it's throw on
errors, and that the core then catches them. I've got proxy classes
handling some fiddly details of the plug-ins.

Should I allow the exception to bubble to the top most point it can in
a call stack, then catch it and log the details, or should I do it
lower down (in the proxy for example) so that the highest level has no
catch statements because all the methods it calls are handle them?

Any suggestions or documentation on this sort of exception handling
would be much appreciated.

Thanks,

Daniel.