Exception handling?
in [MFC]
|
Prev: Deriving from a class derived from a CDialog
Next: How to show underlined menu shortcut letters by default for a contextmenu ?
From: Giovanni Dicanio on 23 Jun 2010 17:03 On 23/06/2010 20:57, Joseph M. Newcomer wrote: > Good observations, all! Thanks Joe! Giovanni
From: David Ching on 23 Jun 2010 17:16 "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:uySKH8wELHA.1272(a)TK2MSFTNGP05.phx.gbl... > Is BCL the current version for 3.0 or earlier (A.D 2.0)? If so, what is > the URL? > > Just did a search and found this thread: > > http://social.msdn.microsoft.com/Forums/en-US/clr/thread/3cbb0121-295c-4b83-b4b1-afddf4ca5257 > > Seeing how things are done with the SSCLI 2.0 is showing me a lot about > the C# and .NET framework. :) > Sigh, it looks like later versions aren't available. Makes you wonder if they released 2.0 only to comply with Justice dept. or something! -- David
From: Joseph M. Newcomer on 23 Jun 2010 17:44 See below... On Wed, 23 Jun 2010 16:07:08 -0400, Hector Santos <sant9442(a)nospam.gmail.com> wrote: >Joseph M. Newcomer wrote: > >>> This is not the case any more with .NET. The StreamWriter constructor: >>> >>> StreamWriter(string filename, bool Append) >>> >>> opens the file in FileShare.Read mode only. >> **** >> How do you append if it isn't opened in Write mode? Did somebody perhaps misread the >> specifications? > > >FileShare mode for other thread/process instances. Not the current >thread instance. **** File sharing does not apply to threads. If you open a file "exclusive", the handle can be used in any thread. **** > >> ***** >>> Whats funny is that I asked this question in MS FORUMS and someone >>> came back suggestion that 95% scenarios this is expected usage and I >>> represent 5% scenarios. >> **** >> 100% of the people who need to append need to write to the file. Sounds like another >> "summer intern" design. >> **** > > >In lieu of something falling thru the cracks, given them the benefit >of the doubt, either it was some buffer caching concern with the .NET >base library or they made a security decision to force .NET developers >to be explicit with the Share more to use. > >The latter works fine so I opt to think it was a security decision, >with some "owner" defining the share mode to be used. Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 23 Jun 2010 17:54 See below... On Wed, 23 Jun 2010 15:29:21 -0400, Hector Santos <sant9442(a)nospam.gmail.com> wrote: > >I don't know Joe. You make me feel like everything I did was wrong. :) > >I'm was APL programmer, tranformation, black boxes, stacking of such >concept was the way I thought and if you do it all in one line, the >better. **** APL was not pure FP, because there was always output. As soon as you have a side effect, you move outside the original FP model. *** > >The concept of Errors was secondary and an side issue really and >should be never be part of the overall FP framework. I mean, of >course, you have to design for it, but its a side issue when it comes >to FP. **** FP always made the assumption that input data was perfect, and algorithms were perfect, and therefore execution would always run to completion successfully. When APL hit an error, it just stopped dead. The code terminated, and told you why. Of course, being a write-only language, it was really hard to decipher what you were doing. [I often have said that the reason I passed one of the PhD qualifiers was that I found a bug in the APL example, proving the rho operator would fail with an error. I then said "You probably intended to write..." and showed the corrected code, and then I answered the question] **** > >Maybe with FP, exception trapping could now be considered even more >important because in classic FP, its not something you think about, >you can't if you wish to stack commands which is also the same idea >with OOPS based protocol stacking. So you need the external wrapping >and help to deal with this extraneous circumstances. > >But then again, APL was a interpreted environment so you had the RTE >around to provide the critical unforeseen trappings for you. > >I think that is an important point in all this, in C/C++ or native >languages, you don't have that RTE around. In .NET or similar CLR >environments you do. So you might not be handling a possible error >condition yourself, but the RTE does have the "global catch." *** Well, the C++ runtime has a default top-level handler, and if you tell the debugger to trap exceptions, you really do have the runtime environment around. The difference is that the *end user* doesn't have it, just the developer. **** > >And I guess even for native images there is an RTE - the OS and its >Doctor Watson recordings. > >So for me, as I am learning .NET (and I have used .NET here and there >in the past 10 years, but never as deeply as I am now), I think the >overall issue for me, is learning what the possible error conditions >with the rich .NET library. Because until you become an expert in it, >all you have to save you is using exception traps. **** I've been fairly generous with try/catch blocks in environments that resembled what .NET now is. It really is a pain. **** > >I like .NET, I think it really helps people in dealing with both code >syntax and also whats NOT possible or even if intellisense doesn't >tell you, its internal global catch all - will. :) *** Is Intellisense actually Intelli*sense* in .NET? Certainly in C++ it is at best Intelli*nonsense*. I've done some C# code, I like the language, but none of my clients have the slightest interest in it. joe **** > >-- > >Joseph M. Newcomer wrote: > >> One of the colossal failures of FP was that in its early incarnataions, it was >> "side-effect-free" code, which makes you wonder why you would ever want to bother >> executing it at all. When FP was coming into style, it was all about having no side >> effects, which meant that if your code ran for a year, it had the same effect as if it had >> not run at all, so you could save a lot of computer time by typing it in and never >> executing it. >> >> Haskell and other modern FP languages have a complex matrix of side effects, from the >> "unsafe" writes-to-a-file types to the pure functions. >> >> I have always been somewhere in the middle; a function should either be executed solely >> for its side effects (changes in the program's internal state or data's external state, >> such as a file, the Registry, etc.) or it should be truly pure functional code, with all >> "side effects" happening solely to its parameter values (e.g., CString &) or expressed in >> its return result. >> >> I also believe that when external state is affected, that the behavior must be >> transactional, that is, either it writes to the file or it does not write to the file, but >> it NEVER writes partial information to the file (and we can debate what should happen on >> "disk full" errors). I'm less of a stickler for parameter effects, and I'm willing to >> accept "If this function returns TRUE, then the CString & contains the result, but if this >> function returns FALSE, the CString & contents are not defined", and I would never pass in >> other than a temporary CString reference in such a case (upon returning TRUE, I might >> "commit" that result to the internal program state by doing an assignment, but I would >> never pass in a direct reference to the program state CString). >> >> Methods which interact do so through member variables of the class that contains them, and >> this state is invisible outside the class (it must always be, at worst, "protected", and >> maybe even "private") >> >> Therefore, I see exceptions as a way of executing something of the form >> {wp() f() assert(oc)} >> where wp() is the weakest preconditions tor successful execution of f, f does the >> computation, and oc is the set of output predicates that must be true. Thus, I view an >> exception as something limited to the {} above, and which can be thrown by wp(), by f(), >> or by the assert(oc), but which always transfers control out of the {} set. In the pure >> FP model, an exception terminates the top-level function. >> joe >> >> joe >> >> On Wed, 23 Jun 2010 14:49:30 -0400, Hector Santos <sant9442(a)nospam.gmail.com> wrote: >> >>> Good Point Giovanni. >>> >>> Off hand, as you mentioned this, my mind is thinking the Two step >>> approach was common with Borland Pascal Oops or POOP as I use to call >>> it. <g> >>> >>> But I never really understood why a FP approach was not a big >>> consideration for construction: >>> >>> SomeClass *sc = new SomeClass(); >>> if (sc == NULL) { >>> //some constructor error occurred >>> } >>> >>> I guess you could do a macro, template or something if you wanted this. >>> >>> -- >>> >>> Giovanni Dicanio wrote: >>> >>>> On 23/06/2010 17:39, Hector Santos wrote: >>>> >>>>> Another problem is that constructors do not lend itself for functional >>>>> programming and exceptions are required, if necessary for the class >>>>> logic. >>>> Note that there is an alternative design: two-step construction. >>>> (This is widely used in MFC as well, e.g. CWnd default constructor >>>> basically puts the object in a safe state, but then you need to call >>>> CWnd::Create/CreateEx). >>>> >>>> With two-step construction you don't need to throw exception in ctor, >>>> because the default ctor just puts the object in a safe state (e.g. zero >>>> the pointers, etc.) and the actual construction is done in a /ad hoc/ >>>> construction method (e.g. Init(), Create()...). >>>> >>>> Note also that if you throw an exception in the ctor, the destructor is >>>> *not* called! So, to write exception-safe code, you should pay attention >>>> to this point and provide proper cleanup code in ctor as well. >>>> This is bad, IMHO. >>>> But this problem doesn't occure in two-step construction: in fact, the >>>> default ctor doesn't throw, and if the Init()/Create() construction >>>> method throws, the destructor is properly called. >>>> >>>> Moreover, you can't call (or is it not safe to call...) virtual methods >>>> in a ctor; but you can call virtual methods in an Init()/Create() >>>> method, after the default ctor put the object in a safe state. >>>> >>>> I like the two-step construction pattern for C++, and I listed above >>>> some reasons (even if the C++-FAQ discourages its use). >>>> >>>> >>>> Giovanni >>>> >> Joseph M. Newcomer [MVP] >> email: newcomer(a)flounder.com >> Web: http://www.flounder.com >> MVP Tips: http://www.flounder.com/mvp_tips.htm Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: RB on 23 Jun 2010 18:02
>I used strsafe.h in VS6 for many years, and it worked quite well. > joe Oh yes, I installed the specific PlatformSDK Feb2003 and have it in my includes. I used it for awhile and then unchecked the includes and moved my original VC6 includes to the top. At the time I thought it might help with some include conflicts I was getting trying some STL stuff. But I read on the net that VC6 had problems with STL on it's own. Anyhow I plan to move on to 2005 for any serious quests, I just still find it convenient to experiment with stuff (except STL ) since I am so used to the IDE. Thanks for the input on exceptions. I learned a little about when I need them or when I may not, but more importantly I learned enough to practice how to use them. (regardless of whether I need them or not) Before I did not have a clue as to even how to get started on implementing them. |