search

ASCOMInitiative / ASCOMRemote

The ASCOM REST based Remote Driver Server and Remote Access Clients
GNU General Public License v3.0
57 stars 15 forks source link

Are some exceptions intentionally not mapped to Alpaca? #57

Closed RReverser closed 3 weeks ago

RReverser commented 3 weeks ago

Not sure if an issue, so it's more of a general question, but I noticed that some ASCOM exception types are not mapped to Alpaca in the ASCOM Alpaca API Reference document, section 2.8.3. "ASCOM Reserved Error Numbers".

For example, I'd expect SettingsProviderError to be mapped to 0x40A and NotInCacheException to be mapped to 0x40D but they're missing in the table.

RReverser commented 3 weeks ago

I guess UnspecifiedError might also be mapped to 0x4FF, but maybe not in Alpaca because any non-reserved error code counts as unspecified?

Peter-Simpson commented 3 weeks ago

Hi Ingvar,

The exceptions you mention come from Platform components and are intended to be caught by devices, and then returned to the client as as more useful errors. This is why they don't appear in the Alpaca list.

These error numbers were added a long time ago and would probably be returned as Utility helper exceptions today, rather than having their own ASCOM exception numbers.

As you say, all undefined error numbers are, by definition, unspecified so there isn't anything really special about 0x4FF. I think the original authors thought of 0x4FF as a "something has gone horribly wrong but I can't characterise what it is" type of error. A bit like the HTTP 500 Alpaca status.

Best wishes, Peter

RReverser commented 3 weeks ago

Makes sense. I just wanted to make sure the mentioned exceptions were not omitted by accident when Alpaca doc was written. Thank you, I'll remove them from my library then.