Re: Exception handling?
Goran wrote:
Now, supposing that you have several places where you might get into a
particular situation, and after seeing the error in your log, you
don't know where that place is (if you will, you know the line, but
it's important t know where did you come from to it). Then, you have
two possibilities:
1. have "debug" logging, turn it on and look there to see where things
start to fall apart. Combine with error log and there you are.
2. "enhance" original error while unwinding the stack (add "context"
if you will).
Or use trace tags. :)
Goran,
I think maybe we are agreeing on the same issues. Trust me, this is
not an issue for me. Flows are not broken, exceptions are truly the
"exception" and not the rule and I have implemented different ideas
different ways, some simple, some more detailed for consumer usage.
So while I may say/write one thing, its not the be taken as its the
only way. :)
The only point I was making is that using a catch all, to me, is
generally more useful until you can chime in on specifics. Note I am
not speaking of an external the code block catch alls, but at the same
level. The external catch all only help you under debug mode since it
has source line numbering.
Not quite sure if I follow, and if I did, I would not be among the
90%.
I really have to press you here: so what code do you have after a
failed call?
Its covered. its not ignored goran. :)
Again, just an example, a good template would be for boolean function:
bool Function(<your parameters>)
{
try
{
// whatever
return true;
} catch (Exception ex)
// do whats necessary or nothing.
}
finally
{
// do whats necessary or nothing
}
return false;
}
but it all depends goran, what if i wanted to have an overloads too?
What if you wanted to have available a boolean return or a exception
model? I have both for some functions.
> Provide some examples, and I am pretty confident that,
even if you used exceptions, you could get what you need pretty easily
(that is, even if you "handle" errors, it's trivial to do what you do
either way, exceptions or error-return).
Sure, I have both. A good example was a NNTP date/time parser. The
syntax is:
yymmdd hhmmss [GMT] RFC 977
[yy]yymmdd hhmmss [GMT] RFC 3977 (replaces RFC 977)
I ended up with two parsing overloading functions
public bool GetNNTPDateTime(string sdt, out DateTime dt)
public DateTime GetNNTPDateTime(string sdt);
so I can use the first overload:
public bool onNEWGROUPS(ClientData ctcp, string args)
{
DateTime dtSince;
if (!GetNNTPDateTime(args, dtSince)) {
ctcp.SendLog("501 Invalid date/time\r\n");
return true; // RETURN ONLY FALSE TO BREAK CONNECTION
}
....
return true;
}
or I can use the exception overload version:
public bool onNEWGROUPS(ClientData ctcp, string args)
{
DateTime dtSince;
try
{
dtSince = GetNNTPDateTime(args)
}
catch (Exception ex)
{
ctcp.SendLog("501 {0}\r\n",ex.Message);
return true; // RETURN ONLY FALSE TO BREAK CONNECTION
}
....
return true;
}
But I ended up using the latter because the parser throws string
exception reasons, part of which also comes from the DateTime
converter exception trap.
At the risk of getting slammed (so be nice <g>), these are the
functions (Keep in mind that these were ported from my C/C++ NNTP
server code, which does not have the exception version).
public static DateTime GetNewGroupsDate(string sdt,
DateTimeKind wantKind =
DateTimeKind.Utc)
{
// parse parts: acceptable formats:
// YYMMDD HHMMSS [GMT]
// YYYYMMDD HHMMSS [GMT]
string[] parts = sdt.Trim().Split(' ');
if (parts.Length < 2)
{
throw new Exception("Insufficient parameters provided");
}
int len = parts[0].Length;
if (len != 6 && len != 8)
{
throw new Exception("Illegal Date - [YY]YYMMDD required");
}
int num = Convert.ToInt32(parts[0]);
int wYear = num / 10000; num -= wYear * 10000;
int wMonth = num / 100; num -= wMonth * 100;
int wDay = num;
if (len == 6) // support RFC3977 6/8 digits semantics
{
int Century = (DateTime.Now.Year / 100) * 100;
if (wYear <= (DateTime.Now.Year - Century))
{
wYear += Century;
}
else
{
wYear += Century - 100;
}
}
if (parts[1].Length != 6)
{
throw new Exception("Illegal time - HHMMSS required");
}
num = Convert.ToInt32(parts[1]);
int wHour = num / 10000; num -= wHour * 10000;
int wMinute = num / 100; num -= wMinute * 100;
int wSeconds = num;
bool gmt = false;
if (parts.Length > 2) gmt = (parts[2].ToLower() == "gmt");
DateTime dt = new DateTime(wYear, wMonth, wDay,
wHour, wMinute, wSeconds,
gmt ? DateTimeKind.Utc:DateTimeKind.Local);
if (dt.Kind == DateTimeKind.Local
&& wantKind == DateTimeKind.Utc)
return dt.ToUniversalTime();
if (dt.Kind == DateTimeKind.Utc
&& wantKind == DateTimeKind.Local)
return dt.ToLocalTime();
return dt;
}
public static bool GetNewGroupsDate(
string sdt,
out DateTime dt,
DateTimeKind wantKind = DateTimeKind.Utc)
{
dt = DateTime.MinValue;
try
{
dt = GetNewGroupsDate(sdt, wantKind);
return true;
}
catch (Exception)
{
}
return false;
}
> Here's my bet: most of the
time, you have error cleanup, for which you should use RAII in e.g. C+
+, or "using" in C#, or you have logging (see above about that). In
rare places, you have "corrective" action. But I bet you that these
are __rare__.
While I am moving towards .NET, nothing will be release (WCLEX is a
"get a deeper feel" of what to expect project) until the proper
error/memory/threading framework is worked out and well understood.
Again, because .NET is richly complex and does so much for you, the
developers need to get a handle of whats already done for you or not.
Probably the less you know the better. :) But thats not the case here.
I have language-independent expectations for well understood solid
behavior. Files, sockets, etc, all work one way - how its implemented
is what needs to be understood.
What that means I must have my "managed" exceptions worked out but I
will now under .NET, allow on "catch alls" to cover the unexpected.
The thing is under .NET you almost always have catch all at the top
level if you use the auto-generated main program code, so that means
that your own catch all is to keep the application running for the
most part, and that can hurt you too.
If anything, that is the big key thing here - do you abort or
gracefully recover for the unexpected catch alls?
This applies to any framework and language and these ideas are 100%
application implementation specific. There are no hard rule. There are
better rules, but never ALL cut and dry.
--
HLS