|
I don't agree with dimzon in this specific example, but he has a good point. Having to pass error messages around as parameters -- making every caller store or otherwise handle them -- is usually unnecessary work for the programmer. The most helpful feature of exceptions isn't handling them, it's the option not to. If a method isn't equipped to handle some conditions, flow simply passes to the previous caller.
Throwing an exception is kinda expensive: it causes a hardware interrupt that has to be bubbled all the way up from the kernel. Figure a few thousand CPU cycles. But performance is totally irrelevant for asynchronous GUI apps like MeGUI...so long as you're not throwing exceptions in a tight loop you'd never notice.
A decent rule of thumb: exceptions should roughly correspond with problems that are important enough to show the user an error message. If a program throws & catches often without bothering the user, it's probably overusing exceptions. (It's crazy what you sometimes see if you run badly written software it under a debugger that's set to catch all native exceptions...)
With IJobProcessor.Setup, I think using an error parameter is appropriate. Any method that calls Setup should know what to do if it receives an error string. But it should be simpler: instead of having a bool and a string, just return a string; if it's not null, it's an error.
|