Best practise for raising/propagating errors?
- From: "PugRallye" <pugrallye@xxxxxxxxx>
- Date: 10 Oct 2006 01:35:14 -0700
Hi,
I'm new to C# but have lots of programming experience with things like
VB, ASP, SQL Server, Oracle etc.
Just starting a new C# project (a DLL and a Windows service to call it)
and trying to figure out best practise for error handling, raising etc.
Basically, should I be logging the errors where there occur (in which
each class will need an instance of the event logger and database code)
and then just have every method as a boolean return so if there's an
error in method x, handle it there and then and return a false to the
calling method?
Or somehow ripple the error back up the tree. In that case, can I
append errors to errors so that I can build a complete stack trace? I
know there's an inner exception, but that's not a collection, it's just
the one right? If I try and access the System.Diagnostics.StackTrace at
the top level then it will only give me the one level (obviously) as
it's unwound itself as I've been throwing errors back up the chain.
Just a bit confused at the moment.
Thanks
.
- Follow-Ups:
- Re: Best practise for raising/propagating errors?
- From: Chris Fulstow
- Re: Best practise for raising/propagating errors?
- Prev by Date: Handling encryption at the application level
- Next by Date: Re: Best practise for raising/propagating errors?
- Previous by thread: Handling encryption at the application level
- Next by thread: Re: Best practise for raising/propagating errors?
- Index(es):
Relevant Pages
|
