[Gtk-sharp-list] Gdk.Color, further comments.
Miguel de Icaza
04 Mar 2003 14:29:28 -0500
> 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