Re: exceptions

Hans Lellelid wrote:

Justin Patrin wrote:

Alan Knowles wrote:

[snip]

This is exactly the kind of thing that I was thinking. You set PEAR_ERROR_RETURN or PEAR_ERROR_EXCEPTION. If the coder selectes exceptions, they get them *instead of* PEAR_Errors. Either should work.

Yes, that's probably the best solution. You do lose (well, bury) the context of the originating error, but the trace should still be fairly usable since it'll just have an additional line or two for the call to raiseError(). One thing that would be hard in that model is to return different kinds of Exceptions. It's certainly easy to imagine classes that could make use of several different types (classes) of exceptions; I suppose you could add another param to your raiseError() or something.

The problem here is just its very hard to deal with this inside your class as you dont know how to deal with errors. However I havent really pondered this in depth. Also it may get problematic if you use a given package with one error style, while another package you use uses that package with the other. The problem with Exceptions is that they impose themselves an everybody. This makes the one options fits all probably fairly difficult. Anyways maybe we can ponder something up. regards, Lukas Smith smith@backendmedia.com _______________________________ BackendMedia www.backendmedia.com berlin@backendmedia.com Linn Zwoch Smith GbR Pariser Str. 44 D-10707 Berlin Tel +49 30 83 22 50 00 Fax +49 30 83 22 50 07