You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have noticed that in several modules warnings and exceptions are being thrown in a very general way. For example:
In the module ee_extra/QA/clouds.py you can find the following code:
platformDict=_get_platform_STAC(x)
ifplatformDict["platform"] notinlist(lookup.keys()):
warnings.warn("This platform is not supported for cloud masking.")
returnx
It could be changed to:
platformDict=_get_platform_STAC(x)
platform=platformDict["platform"]
ifplatformnotinlist(lookup.keys()):
warnings.warn(f"Platform {platform} is not supported for cloud masking.")
returnx
To make the message more descriptive. Moreover, all the code could be refactored by including the platform variable.
In the ee_extra/STAC/utils.py module, if the args argument does not have a "system:id", then it would throw the exception at the end, but that would be very confusing to the client using this functionality. Also, throwing a generic Exception is not the best way to handle exceptions.
That said, for this module, I propose the following implementation:
import ... # etc...# New custom exceptionsclassElementWithoutIdException(Exception):
"""Raised when an element does not have an ID."""def__init__(self, elem):
super().__init__("Element does not have an 'system:id'.")
self.elem=elemclassPlatformNotSupportedError(Exception):
"""Raised when a platform is not supported."""def__init__(self, platform: str):
super().__init__(f"Platform '{platform}' not supported.")
self.platform=platformdef_get_platform_STAC(args: Union[ee.Image, ee.ImageCollection]) ->dict:
...
# Line 25ID=args.get("system:id").getInfo()
ifIDisNone:
raiseElementWithoutIdException(args)
...
# line 50ifpltisNone:
raisePlatformNotSupportedError(plt)
...
These custom exceptions have the advantage of also including the elements that caused the exception to be thrown for use in exception handling. This code exemplifies this:
classCustomException(Exception):
def__init__(self, arg):
super().__init__(f"Look at this arg!: '{arg}'")
self.arg=argtry:
raiseCustomException("A dummy arg")
exceptCustomExceptionase:
print(f"Now a know the arg: '{e.arg}'")
>>>Nowaknowthearg: 'A dummy arg'
If you wish, I can open a PR to include these new changes, and try to find some other cases that are out there. Have a happy day!
The text was updated successfully, but these errors were encountered:
I have noticed that in several modules warnings and exceptions are being thrown in a very general way. For example:
ee_extra/QA/clouds.py
you can find the following code:It could be changed to:
To make the message more descriptive. Moreover, all the code could be refactored by including the
platform
variable.ee_extra/STAC/utils.py
module, if theargs
argument does not have a"system:id"
, then it would throw the exception at the end, but that would be very confusing to the client using this functionality. Also, throwing a genericException
is not the best way to handle exceptions.That said, for this module, I propose the following implementation:
These custom exceptions have the advantage of also including the elements that caused the exception to be thrown for use in exception handling. This code exemplifies this:
If you wish, I can open a PR to include these new changes, and try to find some other cases that are out there. Have a happy day!
The text was updated successfully, but these errors were encountered: