4 ms·

It depends. Did the API document that it could raise an exception if printing isn't supported? Is that unhandled in the client? Then yes, it's a shitty client.

by codexb 3y ago

It depends. Did the API document that it could raise an exception if printing isn't supported? Is that unhandled in the client? Then yes, it's a shitty client. If you're talking about making backwards-incompatible breaking changes to an API, that's another thing.

derefr 3y ago
In the context of the article, no, the existing API never threw (or was documented as capable of throwing) NotSupportedException. The article: > The app that the user installed on the Xbox was probably tested primarily, if not exclusively, on a PC, where printing is always available. I.e. there is no concept in the (desktop) Windows printing subsystem of printing as a feature not being available; on desktop Windows, printing as a feature is available by definition.
- TillE 3y ago
  The mention of NotSupportedException is a little confusing because that's a .NET thing, and the rest of the article is talking about Win32, which is a plain old C API where exceptions don't exist. I guess he's implicitly talking about a C# API built on top of Win32. It's entirely correct to return error codes, and any client is expected to handle that.
  - derefr 3y ago
    Clients are not expected/required, however, to behave correctly in the face of unknown error codes that did not exist or have defined semantics at SDK-version-selection time. Actual exceptions — in languages that have them — are a bit different, in that they “do” something by default: they propagate and unwind unless they’re caught. And so, new (unchecked, if in a language where that’s relevant) exceptions can be introduced after the fact under the presumption that the runtime’s default behavior for propagating unknown exceptions will kick in, and that this will trigger the desired result for applications that weren’t written in awareness of that particular exception. Error codes aren’t like that; they have no default semantics as a class, only explicit default semantics per function and/or per algebraic error-code type, if-and-where documented as such. New error codes simply aren’t meant to be introduced in most APIs, unless those APIs have rules about e.g. generalized default handling for defined code ranges that new codes can be later slotted into. Basically, error codes are weak enums. If you’re writing a dynamic-link library (or a runtime — same thing, basically), you’re not supposed to add new potential values to an enum used as a return value: client code will likely have been written to switch on the value with the known options as cases, and your new value won’t be in there.
  - felsokning 3y ago
    > I guess he's implicitly talking about a C# API built on top of Win32. Correct. The error `ERROR_CANCELLED` is defined in WinErr.h and it's translated via `HRESULT_FROM_WIN32` in the same[1]. It was this change pointed out in `CreateWidget` to get around returning the null pointer that he was suggesting would be better to make the API inert. [1] - https://learn.microsoft.com/en-us/windows/win32/api/winerror/nf-winerror-hresult_from_win32 https://learn.microsoft.com/en-us/windows/win32/api/winerror...
- ryandrake 3y ago
  I think this is the critical piece that should determine how you handle the error. If the API, as used by the client, when the client was programmed, was expected to potentially throw NotSupportedException or return an error code, then doing so sounds like the right way to go. Throwing/erroring is part of the API contract and the client should handle NotSupportedException. If the API was never expected to throw NotSupportedException or return an error code, then all of a sudden starting to throw in a future release breaks the API contract, and the client cannot be expected to handle it sensibly. EDIT: Duh! My comment is useless. This was the exact conclusion that the article came to, too. So instead of reading this comment chain, just finish the article :)

by codexb 3y ago

derefr 3y ago

In the context of the article, no, the existing API never threw (or was documented as capable of throwing) NotSupportedException. The article: > The app that the user installed on the Xbox was probably tested primarily, if not exclusively, on a PC, where printing is always available. I.e. there is no concept in the (desktop) Windows printing subsystem of printing as a feature not being available; on desktop Windows, printing as a feature is available by definition.

TillE 3y ago
The mention of NotSupportedException is a little confusing because that's a .NET thing, and the rest of the article is talking about Win32, which is a plain old C API where exceptions don't exist. I guess he's implicitly talking about a C# API built on top of Win32. It's entirely correct to return error codes, and any client is expected to handle that.
- derefr 3y ago
  Clients are not expected/required, however, to behave correctly in the face of unknown error codes that did not exist or have defined semantics at SDK-version-selection time. Actual exceptions — in languages that have them — are a bit different, in that they “do” something by default: they propagate and unwind unless they’re caught. And so, new (unchecked, if in a language where that’s relevant) exceptions can be introduced after the fact under the presumption that the runtime’s default behavior for propagating unknown exceptions will kick in, and that this will trigger the desired result for applications that weren’t written in awareness of that particular exception. Error codes aren’t like that; they have no default semantics as a class, only explicit default semantics per function and/or per algebraic error-code type, if-and-where documented as such. New error codes simply aren’t meant to be introduced in most APIs, unless those APIs have rules about e.g. generalized default handling for defined code ranges that new codes can be later slotted into. Basically, error codes are weak enums. If you’re writing a dynamic-link library (or a runtime — same thing, basically), you’re not supposed to add new potential values to an enum used as a return value: client code will likely have been written to switch on the value with the known options as cases, and your new value won’t be in there.
- felsokning 3y ago
  > I guess he's implicitly talking about a C# API built on top of Win32. Correct. The error `ERROR_CANCELLED` is defined in WinErr.h and it's translated via `HRESULT_FROM_WIN32` in the same[1]. It was this change pointed out in `CreateWidget` to get around returning the null pointer that he was suggesting would be better to make the API inert. [1] - https://learn.microsoft.com/en-us/windows/win32/api/winerror/nf-winerror-hresult_from_win32 https://learn.microsoft.com/en-us/windows/win32/api/winerror...
ryandrake 3y ago
I think this is the critical piece that should determine how you handle the error. If the API, as used by the client, when the client was programmed, was expected to potentially throw NotSupportedException or return an error code, then doing so sounds like the right way to go. Throwing/erroring is part of the API contract and the client should handle NotSupportedException. If the API was never expected to throw NotSupportedException or return an error code, then all of a sudden starting to throw in a future release breaks the API contract, and the client cannot be expected to handle it sensibly. EDIT: Duh! My comment is useless. This was the exact conclusion that the article came to, too. So instead of reading this comment chain, just finish the article :)