Re: Error reporting from loaded libraries
Re: Error reporting from loaded libraries
- Subject: Re: Error reporting from loaded libraries
- From: has <email@hidden>
- Date: Fri, 3 Feb 2006 21:13:38 +0000
John R. wrote:
>I am starting to use libraries for the first time, specifically using the AppleMods/Loader to load my own "components", and other AppleMods modules. When an unexpected error occurs in one of my own loaded components, Script Editor will break with an alert. However, I don't get info I want about the location of the error. Previously, with a monolithic (no libraries loaded) AS in Script Editor, it conveniently breaks at the offending line. No I have to hunt it down, which is a pain.
>
>Is there any way to get the similar error diagnostics using loaded scripts, or am I out of luck?
Out of luck, unfortunately, as AppleScript doesn't provide tracebacks (yes, this sucks, but AS lacks a lot of features that other languages take for granted, alas). You'll have to provide for any additional error reporting yourself. Add 'try' blocks to the public handlers in each library that prepend the names of the handler and library to the error message, e.g.:
-- begin library foo
on bar()
try
-- do stuff here
on error e number n
error "foo's bar() errored: " & e number n
end try
end bar
-- end library foo
If you do get unexpected errors this will make them easier to track down, but it's also handy when generating 'official' error messages raised by other 'try' blocks in your code, giving callees a nice, readable description of where that message comes from.
And, of course, don't forget to test each library before putting them into use. It's a lot easier to nail bugs while writing individual handlers, rather than waiting till you've assembled the entire program and then wonder why it doesn't all work. Testing and debugging as you go is general good practice, and especially worthwhile in AS's case due to the lousy error reporting abilities.
Do a web search for "defensive programming" for additional tips (e.g. <http://en.wikipedia.org/wiki/Defensive_programming>). For example, when writing general-purpose libraries that'll be used in many different projects over the years I'll often add extra code to their public handlers that ensures their parameters are the correct classes and values; e.g. if I want a whole number greater than zero, I'll add something like:
try
set someParam to someParam as integer
if someParam < 0 then error
on error
error "someParam wasn't a positive integer" number -1704
end try
If I'm really paranoid, I'll add checks for their return values as well.
I don't bother doing this sort of thing in private handlers only used inside that library or in one-off libraries that are only used in a single project, because those sorts of bugs I'll catch during development so it'd only bloat the code for no real advantage. But in libraries you'll regularly reuse, a bit of paranoid programming, judiciously applied, definitely lets you sleep much more comfortably at night. :)
HTH
has
--
http://freespace.virgin.net/hamish.sanderson/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden