Re: When to create your own exception class?

Hi,


I prefer to use a mix approach, I present an user friendly message the most
exact I can (sometimes there is nothing more to tell him but a "An error has
occured, please reintent" or something similar )
and a "Details" button that dump the StackTrace , Message of the catched
exception as well as the inner exception.
In this way when the user call or email me he can give a clue of what
happened. I also create a .log file where I dump the error too.

I agree with you that in general the user has no clue of what caused the
error

cheers,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation


"Jon Skeet [C# MVP]" <skeet@xxxxxxxxx> wrote in message
news:MPG.1d2b9153bb30104298c3ce@xxxxxxxxxxxxxxxxxxxxxxx
> Carlos J. Quintero [.NET MVP] <carlosq@xxxxxxxxxxxxxxxxxxx> wrote:
>> The actual point about exceptions is that they should:
>>
>> - Provide a friendly message to the user in non-technical terms about
>> what
>> happened, why and most important, how to recover from it
>
> I'm not at all convinced about that one. Chances are, the exception is
> dealing with some concept that the user has *no* clue about. For
> instance, say a parameter is null when it shouldn't be - how can you
> explain that in non-technical terms? How many users are going to have
> the faintest idea what null is?
>
> In my experience, you need something at a much higher level to tell the
> user that something has gone wrong. The message displayed may depend on
> the exception generated, but it's unlikely to be known by the exception
> itself.
>
> --
> Jon Skeet - <skeet@xxxxxxxxx>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too


.