How do you guys handle error's from class libraries?

[ahaupt]

Hi all,

I'm currently writing a load of class libraries, but not the main
application iteslf.

I want to provide some method for reporting errors back to the main
application.

At the moment I have a bool errBl and a string errMsg in my classes.
When errBl is ture, one could see what the error was in errMsg.

It works ok, but its quite clunky.

How do you guys do it? Trigger an event or something like that?

Thank you,
Andre

[Frode]

> is a much better object-oritented (and cleaner) approach. But remember to

place the most specific (specialized) exceptions in the first catch
blocks...if you place Exception first, Application and Argument -exception
won't be caught(!!)

hmm..bad english...Appli cation and Argument exceptions will of course be
caught, but not as their specific exceptions...th ey will be caught as
Exception only. The reason for this is because ApplicationArgu ment,
ArgumentExcepti on and all other specialized exceptions inherits from the
Exception class and therefore will be trapped by the Exception catch-block
which is executed first...

[Jon Skeet [C# MVP]]

Frode <Fr***@discussi ons.microsoft.c om> wrote:

is a much better object-oritented (and cleaner) approach. But remember to
place the most specific (specialized) exceptions in the first catch
blocks...if you place Exception first, Application and Argument -exception
won't be caught(!!)

hmm..bad english...Appli cation and Argument exceptions will of course be
caught, but not as their specific exceptions...th ey will be caught as
Exception only. The reason for this is because ApplicationArgu ment,
ArgumentExcepti on and all other specialized exceptions inherits from the
Exception class and therefore will be trapped by the Exception catch-block
which is executed first...

Actually, that's not true - it will fail to compile, with an error such
as:

Test.cs(16,16): error CS0160: A previous catch clause already catches
all exceptions of this or a super type ('System.Except ion')

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Frode]

Jon,

You are absolutly right. I was jumping to fast to the conclusion without
checking - my mistake.
--
-------------
Frode
"Jon Skeet [C# MVP]" wrote:

Frode <Fr***@discussi ons.microsoft.c om> wrote:

is a much better object-oritented (and cleaner) approach. But remember to
place the most specific (specialized) exceptions in the first catch
blocks...if you place Exception first, Application and Argument -exception
won't be caught(!!)

hmm..bad english...Appli cation and Argument exceptions will of course be
caught, but not as their specific exceptions...th ey will be caught as
Exception only. The reason for this is because ApplicationArgu ment,
ArgumentExcepti on and all other specialized exceptions inherits from the
Exception class and therefore will be trapped by the Exception catch-block
which is executed first...

Actually, that's not true - it will fail to compile, with an error such
as:

Test.cs(16,16): error CS0160: A previous catch clause already catches
all exceptions of this or a super type ('System.Except ion')

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[ahaupt]

Hi Ignacio,

Yeah I'm doing that at the moment.

Thanks for the post,
Andre

[ahaupt]

Hi Chris,

Thanks for the little InnerException tip.

Many thanks,
Andre

[ahaupt]

Also,

Would it not be a good design to provide a way for the client to
"plug-in" some functionality into my library (and in this case for
error handling)?

So when a client instantiates my class, I'll provide the option for the
client to specify an error handling method?

Ex: First I show how the client will use the Library, then I show some
public delegate, and finally the implementation of the Library class

//Client
//Error function
public void DisplayError(st ring message)
{....}

//use of Library
ShowError myShowError = new ShowError(Displ ayError);

Library myLibrary = new Library(myShowE rror);
//Some public delegate
public delegate void ShowError(strin g message);

//Library
//Member
ShowError _showError;

//Constructor
public Library()
{..}

public Library(ShowErr or showError)
{ _showError = showError; }

public TriggerError()
{
if(_showError != null)
_showError("Dis play this error to client");
else
throw new Exception...
}

Is this a viable solution?

Is it bad practice to have the error handling in the library rather
than at the client. I'm just thinking that it'll be a real hasstle to
do a try{} catch on the client for frequently used Libraries.

I'd appreciate any comments regarding the design.

[Jon Skeet [C# MVP]]

<ah****@gmail.c om> wrote:

Would it not be a good design to provide a way for the client to
"plug-in" some functionality into my library (and in this case for
error handling)?
The furthest I'd go with that is to allow the client to specify a
logger - and that could be used for diagnostics as well as errors. I
wouldn't try to *handle* the error though.
Is it bad practice to have the error handling in the library rather
than at the client.
Yes, unless the library can truly handle the error and still fulfil its
contract.
I'm just thinking that it'll be a real hasstle to
do a try{} catch on the client for frequently used Libraries.

The client shouldn't be putting try/catch all over the place, because
exceptions shouldn't be generated in the normal success case - usually
you put a try/catch against specific exceptions that you know you can
handle and continue from, and at the top level of the application to
report truly unexpected and unrecoverable (per unit of work) errors to
the user.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[ahaupt]

Thant makes sense. Thanks Jon.

Jon wrote:

<ah****@gmail.c om> wrote:

Would it not be a good design to provide a way for the client to
"plug-in" some functionality into my library (and in this case for
error handling)?

The furthest I'd go with that is to allow the client to specify a
logger - and that could be used for diagnostics as well as errors. I
wouldn't try to *handle* the error though.

Is it bad practice to have the error handling in the library rather
than at the client.

Yes, unless the library can truly handle the error and still fulfil its
contract.

I'm just thinking that it'll be a real hasstle to
do a try{} catch on the client for frequently used Libraries.

The client shouldn't be putting try/catch all over the place, because
exceptions shouldn't be generated in the normal success case - usually
you put a try/catch against specific exceptions that you know you can
handle and continue from, and at the top level of the application to
report truly unexpected and unrecoverable (per unit of work) errors to
the user.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too