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: Hector Santos on 23 Jun 2010 15:29 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. 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. 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." 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 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. :) -- 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 -- HLS
From: David Ching on 23 Jun 2010 15:33 "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:ubMkeYwELHA.4816(a)TK2MSFTNGP04.phx.gbl... > That is why I say the real issue is the lack of documentation or the > "hidden" knowledge that are wrapped into classes. > BTW, you can download the source to much of the BCL (base class library) of ..NET. Also, you can use Reflector to get a really nice code disassembly (that looks so good, it looks like the original source code, except for things like meaningful variable names) for the rest. So you are never really at the mercy of the doc. -- David
From: Joseph M. Newcomer on 23 Jun 2010 15:58 See below... On Wed, 23 Jun 2010 15:58:45 -0400, Hector Santos <sant9442(a)nospam.gmail.com> wrote: >That is why I say the real issue is the lack of documentation or the >"hidden" knowledge that are wrapped into classes. > >When you use fopen(), you know what the possible errors are, basically > > invalid file path, error 2 > not found, for a already exist mode, error 3 > read/write sharing issue, error 5 or 32 > >but regardless of the error code, the #1 idea is that the FILE * >stream variable is NULL. > >Some of the things I am coming across with .NET is that some old >traditional and SOLID concept no longer apply. > >For example, opening a file with append mode. Traditionally, the file >is open/creating with a FILE SHARE READ/WRITE mode. > >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? ***** > >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. **** > >I suggested that for C/C++ developers migrating to .NET, it would be a > higher expectation that opening a file or stream in append mode is >atomic and Read/Write Share mode simply because that is what they are >use to. > >Anyway, my point here is that in C/C++ I don't need an exception trap >for fopen() based appending which I had to add in .NET to find out >what was going on, and after I found out and changed the code so open >the file first in FileShare.ReadWrite mode and pass this to >StreamWrite, I decided to keep the trap in to cover other possible >sceanario, like OUT OF DISK space :) > >-- > > >Giovanni Dicanio wrote: > >> On 23/06/2010 01:51, Joseph M. Newcomer wrote: >> >>> Note that this could be handled as >>> >>> BOOL TryParse(...args...) >>> { >>> try >>> { >>> Parse(...); >>> return TRUE; >>> } >>> catch(..whatever..) >>> { >>> return FALSE; >>> } >>> } >>> >>> It ain't rocket science. And it isn't clear to me how handling the >>> exception results in >>> "bad code". >> >> Sure it isn't (ain't?) rocket science... but do you like a fopen that >> throws an exception if the file cannot be opened? No, I prefer one >> returning an error code. >> The fact that you can't open a file is not an exceptional condition, and >> I prefer code like: >> >> if ( some_open_file_api(...) == error ) >> { >> ... do what you want... (e.g. create the file, or other stuff...) >> } >> ... normal flow >> >> instead of try/catch. >> >> It was clearly written before: the usefulness of exceptions is inversely >> proportional to the number of try/catch you use: if you clutter your >> code with lots of try/catch then IMHO you are overusing (abusing) >> exceptions. >> >> I think exceptions should be used in *exceptional* conditions (like >> David wrote before). >> >> >> BTW: I like these articles from the OldNewThing blog: >> >> "Cleaner, more elegant, and wrong" >> http://blogs.msdn.com/b/oldnewthing/archive/2004/04/22/118161.aspx >> >> "Cleaner, more elegant, and harder to recognize" >> http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/352949.aspx >> >> >> Giovanni >> Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Hector Santos on 23 Jun 2010 16:02 David Ching wrote: > "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message > news:ubMkeYwELHA.4816(a)TK2MSFTNGP04.phx.gbl... >> That is why I say the real issue is the lack of documentation or the >> "hidden" knowledge that are wrapped into classes. >> > > BTW, you can download the source to much of the BCL (base class library) > of .NET. Also, you can use Reflector to get a really nice code > disassembly (that looks so good, it looks like the original source code, > except for things like meaningful variable names) for the rest. So you > are never really at the mercy of the doc. > > -- David > > Getting the SSCLI 2.0 was excellent - helped alot to begin understanding .NET base library. Thats how I found out what FileShare mode was used for the StreamWriter(string filename, bool append) constructor. It also helped me with other tracings. Didn't find one for 3.0, 3.5 or 4.0. 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. :) -- HLS
From: Hector Santos on 23 Jun 2010 16:07
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. > ***** >> 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. -- HLS |