Thanks for the reply, Tod! On Saturday 24 January 2004 14:59, Tod Harter wrote: > There are various concepts here. 1st nothing says that > Apache::AxKit::Exception based exceptions are the 'right' ones to throw, in > fact unless the code is part of AxKit why would you throw an AxKit > exception?
Right! Exactly my idea too. > The type of an exception should tell you WHERE it came from and > maybe WHAT its for if you need that distinction. Yup. > Thus I would generally THROW exceptions of my own devising. If you can't > think of a particular exception you want to throw then why bother to catch > whatever exception was thrown below your code at all? Just let it through > to higher levels, which presumeably know better how to handle it. Yup. > Throwing and catching exceptions should be relatively straightforward, Yeah, I thought so too... :-) > just perldoc on the 'Error' module, Mmmm, did that... :-) As an aside, I often use Konqueror to read documentation. Wouldn't it be very nice to have native POD support in Konqi? I've filed a wishlist bug on that: http://bugs.kde.org/show_bug.cgi?id=70540 > it gives you a complete try/catch syntax Right... But then, it's how to make sensible use of it... I've read a bit more, am I right in thinking that the try/catch syntax implies that you write try { something you know is slightly unsafe and may go wrong } catch { some ways to handle different error situations that may have occured in the try block } ? Following this line of thought, I modified my Taglib code to say: try { $story->save(); } catch Exception::Class::DBI with { my $ex = shift; throw Apache::AxKit::Exception::IO( -text => $ex->error ); } ...but it didn't appear to make life better... Besides, if I remember correctly from the time I was learning Java, it isn't how I remember handling it there? There you would just write exception handling code separately from the code you figured might be unsafe. But as I don't have my Java book here, I could remember very wrong.... So, I still think it's something important I just don't understand.... I tend to think of exception handling as a method of an class; if a method to handle an exception thrown by an object it uses exists, it will be used. If not, the exception will just be passed on to the object that called this object. If was a fatal error, the program will not stop before it is clear that nobody handled it. Thus, I can't see why a catch should by tied to any piece of code, that's rather counter-intuitive to me. Since I thought the idea of using exceptions is about handling unexpected situations, it seems that just handling exceptions for specific pieces of code defeats the purpose of exceptions in the first place, at least some of the purpose. I write this with the hope that someone can point out a flaw in my logic or understanding, and thereby point me to a right track... > If all you need to do is throw an > exception its possible to just call 'die' I know. But actually, what I'd like to do is quite the opposite, the exception has been thrown, allright, but it doesn't give me anything sensible in my error log. If I could catch the exception, but do nothing other than have it rethrow an Apache::AxKit::Exception, with a sensible -text, it would meet my (current) needs perfectly. > > Exception::Class based exceptions work just slightly differently from Error > based exceptions. Check the very bottom of the Exception::Class POD and it > has something to say about that, you need to patch @ISA or some such > foolishness to get try/catch to catch Exception::Class. Yeah, I've read that, didn't understand much of it, but added the suggested line to my taglib, and didn't see any effect. > At the top level AxKit should never see exceptions. That is to say that > being a toolkit it really has no useful way to deal with them, hence the > 'unknown exception' stuff. Either catch them in your taglib code and > generate sensible error messages/behaviour Right. That's the reason why I'd really like to catch any Exception::Class, and have it rethrown as an Apache::AxKit::Exception with a sensible error message, once it is inside AxKit specific code (e.g. a Taglib). That way, I can take advantage of the facilities AxKit has, such as the backtrace, and I may do something to catch some generic errors at some later point (right now, I just like to track them, these error situations would happen if the database is corrupted or something, and that would hopefully be so rare, it is not really a big issue to deal with now). It's more to assist the development than actually dealing with a possibly bad user experience. Also, you're saying that each taglib must handle the exceptions thrown by code it uses? I have a small PerlRequire file that just starts Apache::DBI, it is not something I could do there...? BTW, is there any way in AxKit to have it send the backtrace to the browser, instead of just the "Internal Server Error" page? I think I remember seeing it once, or perhaps it was when I worked with Cocoon. Cheers, Kjetil --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
