On Dec 6, 12:55 pm, ManicQin <Manic...@gmail.com> wrote:
> On Dec 6, 10:44 am, anon <a...@no.no> wrote:
> > werasm wrote:
> > > On Dec 5, 10:59 pm, "Victor Bazarov" <v.Abaza...@comAcast.net> wrote:
> > >> werasm wrote:
> > >>> On Dec 5, 10:53 pm, "Victor Bazarov" <v.Abaza...@comAcast.net> wrote:
> > >>>> werasm wrote:
> > >>>>> On Dec 5, 10:39 pm, "Alf P. Steinbach" <al...@start.no> wrote:
> > >>>>>> Don't use enums.
> > >>>>> Never?
> > >>>> Of course never.
> > >>> Well, care to give some reasons and alternatives?
> > >> Read Alf's response. I totally agree with him on his suggestions.

> > > I've read his response, hence my question (Never, or never
> > > for the particular problem). The question still remains.

> > I think they said never use enums to check errors. Or, have
> > I misunderstood?

> > You can make a base error class, from which all other error
> > classes inherits. Then it is easy to add error codes by just
> > adding classes together with derived classes. When error
> > occurs, throw an error class

> But isn't throwing an error class is much much heavier than
> returning an enum?

That's not really the question. Depending on the type of error,
throwing an exception might not really be appropriate.

None of which has anything to do with the poster's original
question, of course.

> I dont see any usability/readability benefits in throwing
> exceptions over returning error codes.

If the error can't be handled locally, an exception will
propagate it up. If it can be handled locally, of course, an
exception is just a means of making it more awkward for the
user. As a general rule, a function should use a return code
unless there is no reasonable chance of handling the error
locally.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34