[Gtk-sharp-list] Gdk.Color, further comments.

[Miguel de Icaza]

Hello,

> Well, if "probing" is the only reason you want to get rid of exceptions,
> then maybe we should create a API specifically for "probing".  (Is that
> the only reason to NOT use exceptions?)
> 
> For stuff like the "End of File", these things are already "returned".
> (Instead of being thrown.  It is only the "unusual" errors that
> are being thrown.)
> 
> Alternatively, I could create 2 different implementation of
> System.IO.Stream (and other classes).  One would use exceptions and
> the other wouldn't.
> 
> Or, I could make one implementation.  But you could configure how
> the class reports errors.
> 
> What does everyone think about that????

Remember one thing: exceptions are very expensive to create, to throw
and to catch, CPU-wise.  Very expensive. 

When you are building a file manager, you will need all the speed tricks
that you can to avoid pissing off people for unresponsive call.  That is
why file managers become ugly: they have to pull every possible trick to
avoid blocking, to get the list of files as quickly as possible, to
avoid hitting the disk twice, and so on.

>From a pure computer-science perspective, yes, throwing exceptions might
be nice, but it is not practical.  If you want to have an exception
based API, you can always have a wrapper to do it.  But if you use
exceptions as the foundation, you can not efficiently implement the
other mode.

Miguel.