Re: Exception handling?
Giovanni Dicanio wrote:
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
You see, you made my point, one has to be knowledgable of the error
exceptions and traps for each class in order to consider specific
trappings. :)
But as I also pointed out, I came across where using the specific
trapping MAY only apply to a specific binding or integration.
Yes, when I was diagnosing and debugging the issue I came across with
the Live ID reference assembly from a DLL rather than the example
usage with a direct reference in the EXE example, I studied up on the
exception levels and inner exception stuff.
I figured, atleast for now, I can cover both usages with the Live ID
SDK DLL is bound to an EXE or my helper DLL using the catch all.
I saw it somewhat of a chicken and egg situation for general
applicability. If a DLL is missing, then any specific DLL Exception
class will not be available, hence the critical abort.
I have to go back to verify what happen and what I found under debug,
but I think that is what happen here.
In my helper DLL, I have a InitializeWindowsLive() class method:
private bool InitializeWindowsLive()
{
try
{
oIDMgr = IdentityManager.CreateInstance(AppId, AppName);
return oIDMgr != null;
}
catch (WLLogOnException wlex)
{
ShowError("WLLogOnException: {0}",wlex.message);
}
catch (Exception ex)
{
ShowError("InitializeWindowsLive(): {0}" + ex.Message);
}
return false;
}
When Program.cs had the original usage of the SDK example using the
System.IO.FileNotFoundException catch only, I guess delayed loading
occurred when the LiveID DLL was bound to the EXE. Hence this catch
would work.
But I used a helper DLL and the LiveID DLL was bound to it, the
InitializeWindowsLive() error if I remember was that the
WLogOnException was not found because the DLL was not found.
I don't remember if I had the 2nd catch in the Initialize function or
it was part of the solution, but for sure the program.cs could not use
the System.IO.FileNotFoundException catch. I had tried to use the
InnerException too I recall, overall I was dumping everything to see
what I can "hold on" too to catch the overall error of the separate
LiveID DLL not being installed on user machine.
The point is that even using specific exceptions for the library MAY
NOT work if the library itself is missing.
I MAY or MAY NOT be saying that using a catch all may be necessary
MOST of the time.
--
HLS