Re: Exception management question...

From: craig (e_at_mail.com)
Date: 01/24/05 

Date: Mon, 24 Jan 2005 12:02:45 -0500

Thanks for the detailed exlplaination. I printed it out so that I can study
it.

Let me ask you this...

There is code in my app that follows this general pattern:

Private void UpdateName(Guid ObjectID, String Name)

{

      object myObject = GetObject(ObjectID)

      if(myObject != null)

{

myObject.Name = Name;

}

}

I see this as a problem, because it has the potential to swallow a logic
error in which an invalid ObjectID parameter is passed resulting in the
GetObject method returning null. Would it be better to rewrite this as:

Private void UpdateName(Guid ObjectID, String Name)

{

      object myObject = GetObject(ObjectID)

myObject.Name = Name;

}

This allows an exception to be thrown with the next line of code attempts to
set the property of a null object reference. Or would it be better to write
this as:

Private void UpdateName(Guid ObjectID, String Name)

{

      object myObject = GetObject(ObjectID)

      if(myObject != null)

{

myObject.Name = Name;

}

else

{

            throw new InvalidArgumentException("ObjectID is invalid");

}

}

Thanks again for your input!!

"David Levine" <noSpam12dlevineNNTP2@wi.rr.com> wrote in message
news:uI6tyD0$EHA.1084@tk2msftngp13.phx.gbl...
>
> "craig" <e@mail.com> wrote in message
> news:%23tpPbUy$EHA.3256@TK2MSFTNGP11.phx.gbl...
>>2 questions:
>>
>> 1) What is a launcher?
>
> A managed application that launches another windows (.net) application. It
> could do so in a separate process, or load and execute it in another
> appdomain within the same process; the latter is what I have been
> referring to in the preceding dicussion.
>
>>
>> 2) What do you mean by an exception being swallowed?
> The following demonstrates swallowing an exception...
> try
> {
> //evil code here
> }
> catch(Exception ex)
> {
> // trace, log, or ignore it. But it is not rethrown from within this
> catch block
> }
>
> In this example, all exceptions will be caught in this catch block.
> Because the exception is not rethrown then the exception ends here.
> try
> {
> }
> catch(NullReferenceException n)
> {
> }
>
> In this case only a single exception type is caught, dealt with, and it
> ends here. All other exception types are not caught so they continue to
> propagate up the callstack.
>
> {
> }
> catch(Exception ex)
> {
> if ( canHandleIt )
> { //handle and recover here
> }
> else
> throw new Exception("I fell down and can't get up.",ex);
> }
>
> In this example, if the exception can be handled it is dealt with and
> ended here, otherwise it is rethrown so that an exception continues to
> propagate up the callstack. I used a new exception object, using the
> original exception as the inner exception. I prefer this technique as you
> can add valuable context information so that when it is eventually
> displayed to the user s/he will get a better sense of what went wrong and
> can more effectively deal with it. This referred to as the
> catch-wrap-throw technique.
>
> A variation on this is to use
> catch(Exception ex)
> {
> // do some processing
> throw;
> }
>
> A naked throw tells the CLR to continue to propagate the original
> exception unchanged, including leaving the original stack trace alone
> (unfortunately, in current version this actually resets it to the LOC
> where the throw is, but that is supposed to be fixed).
>
> I recommend against the following...
> catch(Exception ex)
> {
> throw ex;
> }
> and
> catch(Exception ex)
> {
> throw new SomeException("Some message")
> }
>
> The problem with the 1st is that it adds no additional information yet
> loses the original stack trace. The 2nd has a similar problem and does not
> even preserve the original exception type, so you lose even more data.
> However, this form *might* be useful if this is a security sensitive
> operation and you want to hide the real exception type.
>
> I prefer the catch-wrap-throw technique as it adds info and does not lose
> anything. I often times will throw the same exception type (i.e. I clone
> the type) if there is no other type that I can map it to that adds useful
> information.
>
>> My app is a windows forms app and I am really struggling to find a
>> consistent, logical strategy for implementing exception management.
>> Looks like I am going to have to invest some time studying the info in
>> this thread.
>>
>> Are the two of you suggesting that unhandled exceptions should be allowed
>> to propagate up to a global exception handler which logs the exception
>> and closes down the app? This would mean that the following code should
>> never be used:
>>
>
> If it is unhandled then by definition it is propagating upwards to a
> global handler. If you do not provide one the system will provide a
> default action. For UEs that occur on the main thread, or threads that
> originate from unmanaged code, the application is terminated. For all
> other threads the UE is discarded and you get no other indications that
> this occurred. The terminate-or-run policy is currently set by the CLR
> itself, not the application.
>
> The app can subscribe to a UE event, and it can take some action within
> that event, such as put up a messagebox, log it, etc., but if the system
> has determined that the app should terminate the UE handler has no means
> of changing that. In other words, if a UE occurs and the system decides it
> should terminate the app, then wave bye-bye because you cannot change that
> within the UE handler. There's a flag in the event args that indicates if
> the app will terminate once the handler has run to completion.
>
> When a UE occurs you can terminate the app on your own (call
> Envurinment.Exit()) but you need to be aware that if you do then all other
> threads in the system are frozen and never resume - this means that
> unfinished finally blocks will not run and will never execute the clean up
> code (this is v1.1 behavior - I don't know how this might have changed for
> Whidbey).
>
> This is one of the reasons I do not like the global UE strategy - you
> leave the basic decision of terminating the app or allowing it to continue
> to the system - I believe this ought to be an application policy decision.
>
> You should have a registered handler, if for no other reason that
> exceptions do not get "lost" when a UE occurs on a thread which will
> silently swallow the exception - that's usually a bug.
>
>
>
>
>> try
>> {
>> //program logic
>> }
>> catch(Exception ex)
>> {
>> //response to exception
>> }
>>
>> I have used code like this all over in my app.
>>
> Like so many other things, it depends...this code may be fine; it depends
> on what you want it to do. If the catch handler completely deals with it
> then this is fine. If it does not, then if this is the final boundary of
> the application you must make a call about whether to allow the app to run
> or terminate it. If it is not, then you need some means to propagating the
> exception upwards to the final handler in the system.
>
>
>
>

Relevant Pages

  • Re: Need crash dump from Managed app
    ... is to create a TextWriterTraceListener and start logging every P/Invoke call ... The exception handler was never executed. ... I have a test C++ app with the following startup code: ...
    (microsoft.public.pocketpc.developer)
  • Re: Exceptions Thrown in Background Threads
    ... The only time where it is not practical is when the exception actually ... ought not to be in a UE handler. ... One of the fields in the unhandled exception ... app immediately thereafter - the app has no control over this. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Try Finally...
    ... >>2) Terminate the application ... implemented as an exception handler, ... that could be set inside the user code of Finally. ...
    (comp.lang.pascal.delphi.misc)
  • WinForms bug? ThreadException not invoked on Exceptions in system code pre-processing the messag
    ... Message Queue and invoking the appropriate handler. ... if an Exception is raised during the PRE-PROCESSING of a Windows ... before this point in the app... ...
    (microsoft.public.dotnet.framework.windowsforms)
  • Re: Application xxx has encountered a serious error and must shut
    ... Chris Tacke, Embedded MVP ... use of Queueacross multiple threads - and even my exception ... stopped my Serial port thread - last time it stopped the whole app:-O. ... NB I replaced the MS SerialPort with OpenNetCF Serial and this seems ...
    (microsoft.public.windowsce.app.development)
Quantcast