[Pyogp] Exceptions in caps.py

[Christian Scholz]

Hi!

I just checked in some use of exceptions in caps.py and some tests
testing them. You can find the exceptions by searching for "exc" and you
can find example of how to catch them (or how they actually look like)
in tests/caps.txt at the bottom.

I also added some deserialization exception at the bottom of caps.py and
separate tests for GET and POST.

Those exceptions now also have a string representation which prints out
more details instead of just "ResourceNotFound".

Included are also the logging changes.

Next step might be to add some more high level caps like for catching a
login failure.

cheers,

Christian

[Enus Linden]

Christian,

I like the path that exception handling seems to be taking. I'd be
comfortable moving forward with this version as an initial version for
full adoption in the lib.

Per logging, it looks as if python's native logging can suffice. I would
like for the verbosity of logging to be available as a parameter in some
way. For example, have a settings somewhere that specifies the level of
logging, and outputs based on that setting.

To illustrate:

settings.py (or something like that) contains a variable:

loglevel = 0 (where 0 is none, and 1-5 are mapped to DEBUG, INFO,
WARNING, ERROR, CRITICAL)

then, in caps.py

if (loglevel >=1):
log(DEBUG, 'log string')

if (loglevel >=2):
log(INFO, 'log string')

if (loglevel >=3):
log(WARNING, 'log string')

etc, etc

This would allow for silent applications, or verbose ones, depending on
the setting....

Thoughts?

~e

Post by Christian Scholz
Hi!
I just checked in some use of exceptions in caps.py and some tests
testing them. You can find the exceptions by searching for "exc" and
you can find example of how to catch them (or how they actually look
like) in tests/caps.txt at the bottom.
I also added some deserialization exception at the bottom of caps.py
and separate tests for GET and POST.
Those exceptions now also have a string representation which prints
out more details instead of just "ResourceNotFound".
Included are also the logging changes.
Next step might be to add some more high level caps like for catching
a login failure.
cheers,
Christian
_______________________________________________
https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/pyogp/attachments/20080902/ed768ffd/attachment.htm

[Christian Scholz]

Hi!

Post by Enus Linden
I like the path that exception handling seems to be taking. I'd be
comfortable moving forward with this version as an initial version for
full adoption in the lib.

Cool :-)

Post by Enus Linden
Per logging, it looks as if python's native logging can suffice. I would
like for the verbosity of logging to be available as a parameter in some
way. For example, have a settings somewhere that specifies the level of
logging, and outputs based on that setting.

This can actually be configured by the application, usually with a
configuration file. I will provide examples.. The idea here is that the
library logs as much as possible and the application then picks and
chooses of what to log (and where).

That means that caps.py would not need to be changed.

The logging lib also supports things like rotating logfiles, remote
logging, logging by component etc. So you can also choose just to get
messages from e.g. the caps modules but ignoring everything else.

I think it's quite capable but not so well explained in the docs.

Example comes as soon as I have some time to post it or check it in.

-- Christian

Post by Enus Linden
loglevel = 0 (where 0 is none, and 1-5 are mapped to DEBUG, INFO,
WARNING, ERROR, CRITICAL)
then, in caps.py
log(DEBUG, 'log string')
log(INFO, 'log string')
log(WARNING, 'log string')
etc, etc
This would allow for silent applications, or verbose ones, depending on
the setting....
Thoughts?
~e

Post by Christian Scholz
Hi!
I just checked in some use of exceptions in caps.py and some tests
testing them. You can find the exceptions by searching for "exc" and
you can find example of how to catch them (or how they actually look
like) in tests/caps.txt at the bottom.
I also added some deserialization exception at the bottom of caps.py
and separate tests for GET and POST.
Those exceptions now also have a string representation which prints
out more details instead of just "ResourceNotFound".
Included are also the logging changes.
Next step might be to add some more high level caps like for catching
a login failure.
cheers,
Christian
_______________________________________________
https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp

------------------------------------------------------------------------
_______________________________________________
https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp