When is an event null?

[Jon Skeet [C# MVP]]

Too bad DotNet exceptions are so cumbersome (heavyweight, difficult to
mask out in debugger) or I'd just suggest doing the Pythonesque
approach of "just do it and catch the exception"... well, that and the
fact that a NullReferenceException could also come from the actual
events being called, the hiding of which would be a Very Bad Thing....
any handling logic to try and discern what object was null that threw
the exception would have the same threading problems as the original
plan...

It would be a complete abuse of exceptions, IMO. Not having any
subscribers is *not* an exceptional situation for an event.

(As for the "heaviness" of .NET exceptions - if you mean in terms of
performance, you might like to read
http://www.pobox.com/~skeet/csharp/exceptions.html - it's a pet topic
of mine

 

[Martin Z]

Well, it's a matter of style. I first learned proper OOP coding in
Python, and in Python the idiom has always been "just try it and handle
the exception" rather than check-first. This works in Python because
exceptions are hardly more expensive than any other language construct.
If you keep the catch block close to the call then the legibility of
the concept does not suffer. In general, exceptions are treated as the
de-facto standard approach for any object that can return different
types of data.

However, this approach is inappropriate in C#, for three big reasons:
1) the cost of exceptions, while less than, say database access, is
non-trivial in other operations. For example, a problem in 1.1 was
parsing - no way to parse into an int without risking an exception. If
you had piles of strings coming in that you had no idea if they were
valid ints or not, and you had to check each and every one for
int-ness, and using ParseInt and handling the exception case as "no,
it's not an int", then you'd really feel the cost of exceptions (early
in my coding days I made this mistake using Hashtables in some language
or another).

2) Convention. C# coders don't expect the just-try-it idiom. Be kind
to your maintainers.

3) The debugger - C# has a handy "break on all throws" feature which is
very helpful... particularly given the utterly pathetic amount of
information returned by many exceptions, this stack-break is often the
only way to discover the true source of an error. Having code that
uses a lot of exceptions for expected events makes this sort of
debugging impossible.

So I obey the rule - but I don't like it. There are too many cases
where the "just try it" approach is the most computationally sensible
way of doing things. Remote operations, for example - testing the
viability of an operation is as expensive as the operation itself, and
thus is wasteful in those cases.

Sorry for the offtopic rant, it's just that the "exceptions for
unexpected failures ONLY" concept is considered to be a universal truth
by many programmers, and I've always found that irksome.

 

[Jon Skeet [C# MVP]]

Sorry for the offtopic rant, it's just that the "exceptions for
unexpected failures ONLY" concept is considered to be a universal truth
by many programmers, and I've always found that irksome.

It was a refreshing read. There are certainly advantages to "try it and
see" - notably atomicity. For example, if you check whether or not a
file exists and then try to read it, you need to be able to handle the
case where the file is deleted just before you open it (or can't be
read) anyway.

It just feels different when it's so easy to check for this one
condition - and where you'd often handle the single condition of there
being no handlers differently to a real, "worrying" exception being
thrown. I think that's the nub of my objection to using exceptions in a
cavalier manner - if they're reserved for "something significant is
wrong" then it's easier to decide that, for instance, all exceptions
should be logged, and whatever transaction you're in the middle of
should be aborted, etc.

I need to think about it further though...