> But if you need to report back errors via exceptions (since that is the[color=blue]
> model) then it's not up to your component if the dev shows it in the page
> or not.[/color]
I suppose I wasn't being too clear. I didn't mean that the DLL classes
should handle the errors. I meant that the client (ASP.Net) application
should handle them, for the most part. I do use some structured exception
handling in my business classes, but usually pass the exceptions up the line
to be dealt with by the client.
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.
"Brock Allen" <ballen@NOSPAMdevelop.com> wrote in message
news:b8743b11228108c7868237d1ebbe@msnews.microsoft .com...[color=blue]
> Right, so as kevin said don't let exceptions propagate outside your API
> calls is one way to solve that. But if you need to report back errors via
> exceptions (since that is the model) then it's not up to your component if
> the dev shows it in the page or not.
>
> -Brock
> DevelopMentor
>
http://staff.develop.com/ballen
>[color=green]
>> Good info that I didn't know about. However, this seems to deal with
>> a setting within the web app. I want something in the DLL that will
>> cause error messages from exceptions to be raised in the ASPX page,
>> showing the line within the ASPX that is in error. Basically this DLL
>> will be a commercially marketed component and I don't want the code
>> inside the DLL to ever be seen by the user (which is currently
>> happening when the DLL code is shown in the SOURCE ERROR section of
>> the error page)
>>[/color]
>
>[/color]
