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: David Ching on 23 Jun 2010 11:25 "Giovanni Dicanio" <giovanniDOTdicanio(a)REMOVEMEgmail.com> wrote in message news:eDb2QArELHA.4120(a)TK2MSFTNGP02.phx.gbl... > "Vexing exceptions" > > http://blogs.msdn.com/b/ericlippert/archive/2008/09/10/vexing-exceptions.aspx > Great article and illustrative of what we were trying to say! -- David
From: David Ching on 23 Jun 2010 11:31 "Goran" <goran.pusic(a)gmail.com> wrote in message news:d5d4107e-3b75-4a3f-be81-45c2c0d916a2(a)d37g2000yqm.googlegroups.com... > Thing is also that .NET exceptions, like MFC (and VCL) ones, can > really be costly: they are on the heap, they are info-rich (e.g. > there's a CString inside) etc. But despite that, I still say, just > like you: there's no performance problems with exceptions; if there > is, programmer is doing something horribly wrong in 99% of cases ;-). > > And absolutely, programmer does not know, by looking at any non- > trivial the code, where it's slow, too! > Hi Goran, well I understand your point. My favorite string class is CString, and I use it by default. But I once had a situation on startup where the profiler showed a lot of time in copying CString, so we replaced a few lines of code to use lstrcpy() instead of CString, and that saved significant time. So I understand your point that exceptions in general are very usable, but it's only in certain situations where they cause a noticeable problem. And perhaps .NET exceptions are more costly than C++ ones, I don't know. (I didn't use exceptions in C++, I only started using them because I had no choice when I went to .NET.) I will say it is a common in .NET programming to run in the debugger with first chance exceptions being enabled so you are well aware of any exceptions being thrown. And when I eliminate those, the program does seem to run a bit faster, but I don't know if that is my imagination or not. It does seem avoiding unnecessary exceptions is emphasized more in .NET, but I always thought that was because they are used more in .NET. Also perhaps because it involves loading more assemblies to deal with the exception, and loading assemblies is expensive. Thanks, David
From: David Ching on 23 Jun 2010 11:34 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:398426d1hill1o2bbf1m7ddm5jt4sohumm(a)4ax.com... > Well, we were not discussing .NET exceptions, we were discussing C++ > exceptions. Since I > had never heard of either Parse or TryParse, there was no easy way to > detect these were > something in .NET and not in some part of C++ I had not seen. > > I have no data on .NET exception handling. > Why does it make a difference if it is .NET or C++? The concept is exactly the same. > As you point out, if you have a lot of really bad input, why is it really > bad input? I > would have applied a Parse operation to something vastly more complex than > an integer > (e.g., an entire script), in which case an exception makes more sense. I > had no idea it > applied to concepts as trivial as just parsing numbers. Again, what does it matter if you are parsing ints or scripts? The concept is exactly the same. -- David
From: Giovanni Dicanio on 23 Jun 2010 11:39 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
From: Giovanni Dicanio on 23 Jun 2010 11:44
On 23/06/2010 17:39, Hector Santos wrote: > public bool SearchForums(string sPattern) > { > try > { > > Regex rgx = new Regex(sPattern, RegexOptions.IgnoreCase); > foreach (var forum in ForumsList) > { > MatchCollection matches = rgx.Matches(forum.Description); > if (matches.Count > 0) > { > /// got something > } > } > return true; > } > catch (Exception ex) > { > MessageBox.Show("Regular Expression Error: " + ex.Message); > } > return false > } > > This turned out to be nice catching(Exception) in C# is like catch(...) in C++: basically you are swallowing everything... but IMHO you should only process Regex related exception. I don't know the details of .NET Regex, but I think they should have designed an /ad hoc/ exception class for regex (e.g. RegexError), so that you could selectively catch RegexError and not swallow unrelated exceptions. Note also that C# exceptions are better designed than C++ ones. For example, you can put localized strings in C# exceptions, it is possible to nest C# exceptions (see e.g. Exception.InnerException property) to provide better diagnosis, etc. Giovanni |