Re: Why does this object need to be cast?

From: Michael S (a_at_b.c)
Date: 02/23/05 

Date: Wed, 23 Feb 2005 21:39:41 +0100

"Jon Skeet [C# MVP]" <skeet@pobox.com> wrote in message
news:MPG.1c86e93cb525136198bdb0@msnews.microsoft.com...
> Michael S <a@b.c> wrote:
>
> <snip>
>
>> My point being, do not code checks in .NET that the CLR will check for
>> you.
>> If .NET throws an excpetion, it's a bug. Log it, mail it, do whatever
>> stuff
>> you want with it, but don't protect yourself from it.
>
> That's only true if the caller is definitely meant to pass in an
> instance of the specific type though.

-It typically is just so for applications. When we build applications we
only sew things up for which with managed code we have protection. For
writing low level classes, overiding operators and such, Exception handling
should be mandatory. But for applications, we should rely on the protection
and the documentation there is.

This is the Java pitfall with checked exceptions. It goes like this:

When I write a method in Java, I might receive a reference type. Hence I
better by a good java-dev and check for null first and type then. This
implies I have to throw two checked exceptions. But the one calling the
method knows very well that the object is there and is of the right type.
But stand no chance no less. The caller must do a silly try/catch or forward
it upwards which makes even less sense.

The caller will sport code that implies that something may go wrong when it
cannot possibly do so.

I like Anders Hjelsbergs view on this. - Never force a caller to handle
exceptions. Good code have a finally/catch ratio of 10 to 1.

> Consider a method which copies the contents of one stream to another -
> if a MemoryStream is passed in, the MemoryStream.WriteTo method is the
> fastest way of going; otherwise, you need to copy block by block. That
> could be written: 

---
*snip*
---
> Nothing wrong with that.
- Nothing wrong if you're writing a general component. But if you're 
building an application, you fool the maintainer as to beleive that the 
stream may or not work, when it always does. Hence the protection is not 
only overkill, but may take the maintainer on a short, but dead end, trail 
while debugging.
> Where you're going to throw an exception if the object is the wrong
> type, there may still be value in throwing a different exception to the
> default InvalidCastException - for instance, throwing an
> InvalidArgumentException may be more appropriate (and allows you to
> specify which parameter was wrong).
- This may be true for C++ and Delphi, as bugs in a release compile often 
just yields an access violation and a hexcode address. But for managed code, 
most developers just want to find the .cs file and line-number to fix the 
darn simple bug.
> Jon Skeet - <skeet@pobox.com>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too
- Thanks Mr. Skeet. Looking forward to your reply.
- Michael S

Relevant Pages

  • Re: Some questions about handling exceptions and when to throw them
    ... In the event that a customer can't be ... Possibly even my own exception, ... because the caller should have checked first. ... If GetEmployeeInfo fails, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Some questions about handling exceptions and when to throw them
    ... So in those cases throwing an exception would be a good decision. ... because the caller should have checked first. ... PrinterInfo GetEmployeeDefaultPrinter ... If GetEmployeeInfo fails, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Choosing not to throw exceptions like IllegalArguementException
    ... preventing debug from happening at all. ... like a recipe for converting easily debugged problems into subtle wrong ... Imagine the TreeCellRenderer wich throw an exception, and prevent the JTree from any repaint success, only because some bug happened before, which broke a specific assumption, and now there is the "impossible case" happening. ...
    (comp.lang.java.programmer)
  • Re: Exception handling help please
    ... > void MyFunc() ... > Then in the caller: ... Second, if you throw an object of a class derived from MyException, ... The copy of the exception object specified in the throw expression ...
    (comp.lang.cpp)
  • Re: Find rare bugs - SEH and c++ exception handling
    ... Unfortunately the bug occurs only "on the read" it's not that easy (or ... I can't introduce MessageBoxes because they ... It really seems that I neet a lot of patience. ... When the kernel detects an application exception, ...
    (microsoft.public.pocketpc.developer)
Loading