3 ms·

That's a huge pain point, but I'm curious! What would be a good approach in your opinion? I'm not questioning the exit/print error and carry on, that's plainly

That's a huge pain point, but I'm curious! What would be a good approach in your opinion? I'm not questioning the exit/print error and carry on, that's plainly wrong. When working on private projects/libs, my functions usually return an enum error type, and do all data handling - be it arguments or returns - through pointers passed as args; I mean, I think that's the usual convention, but you clearly have way more experience, so I thought about asking! :) Looking at you, syscall!

zabzonk 3y ago
well, i guess in C you should return a value indicating the error probably via a struct that contains the error and the success data. C programmers seem to have a terrible aversion to returning structs (possibly they don't realise that you can do it?) where in other value-based languages (e.g. c++, go) it is very common. of course, there are reasons for mucking around with pointers. but down that route lies pointers-to-pointers, and eventually madness.
Const-me 3y ago
On Windows, this problem is already solved well. Return 32-bit integers which conform to that spec: https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/0642cb2f-2075-4469-918c-4441e69c548a https://learn.microsoft.com/en-us/openspecs/windows_protocol... Possible to pack OS errors, third party library specific errors, and other classes of errors into a single value. Technically, you can implement that spec for all OSes. I did a few times, defining vendor-specific facilities for Linux components I used, like xwindows, drm/kms, etc..
- frankjr 3y ago
  How do you return an error that communicates "missing quote on line 42 character 200"? A much better solution is to use std::expect (or something home baked if not available) and make the error type something that holds an actual context. HRESULT is a remnant of the past, not something you should replicate in your own code if you have the choice. https://en.cppreference.com/w/cpp/utility/expected https://en.cppreference.com/w/cpp/utility/expected
  - zabzonk 3y ago
    oh dear - i remember teaching people on COM training courses about HRESULTs - never again, please!
    - pjmlp 3y ago
      Unfortunately WinDev has decided all modern Windows APIs are based on COM. They aren't alone, Apple's XPC, Android and Fuchsia's Binder, and even Linux D-DBus, aren't much different. They have much better tooling though, something that Microsoft folks keep ignoring, so I understand where the pain comes from.
  - Const-me 3y ago
    > How do you return an error that communicates "missing quote on line 42 character 200"? For that use case you gonna need some other piece of data besides the error code. Maybe another type like json_error_t in Jansson library. Or maybe a special strings, like the ones returned by sqlite3_errmsg() in SQLite library. > not something you should replicate in your own code if you have the choice I believe HRESULT, despite rather old, is still the best error handling strategy overall. Language-specific solutions like std::expected don’t work because all complicated software is written in multiple programing languages. For example, the entire ML ecosystem uses Python. 32-bit integers and strings are as language agnostic as you can possibly get. Enums don’t work because most non-trivial libraries have an unbounded number of possible error conditions. You made a parser library for some format, defined an enum containing all possible failures of the parser, but then a user tried to parse a file he doesn’t have read access to. The failures need to include disk I/O errors. Another user gonna parse their source file from a mounted network share, the failures returned from your parser now need to include TCP/IP errors.
  - fweimer 3y ago
    Typically, you have a parser handle and can use that to query it about various aspects of its state. Here it would include line number, character offset, and byte offset. The type of error can be encoded in the error return value.

zabzonk 3y ago

well, i guess in C you should return a value indicating the error probably via a struct that contains the error and the success data. C programmers seem to have a terrible aversion to returning structs (possibly they don't realise that you can do it?) where in other value-based languages (e.g. c++, go) it is very common. of course, there are reasons for mucking around with pointers. but down that route lies pointers-to-pointers, and eventually madness.

Const-me 3y ago

On Windows, this problem is already solved well. Return 32-bit integers which conform to that spec: https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/0642cb2f-2075-4469-918c-4441e69c548a https://learn.microsoft.com/en-us/openspecs/windows_protocol... Possible to pack OS errors, third party library specific errors, and other classes of errors into a single value. Technically, you can implement that spec for all OSes. I did a few times, defining vendor-specific facilities for Linux components I used, like xwindows, drm/kms, etc..

frankjr 3y ago
How do you return an error that communicates "missing quote on line 42 character 200"? A much better solution is to use std::expect (or something home baked if not available) and make the error type something that holds an actual context. HRESULT is a remnant of the past, not something you should replicate in your own code if you have the choice. https://en.cppreference.com/w/cpp/utility/expected https://en.cppreference.com/w/cpp/utility/expected
- zabzonk 3y ago
  oh dear - i remember teaching people on COM training courses about HRESULTs - never again, please!
  - pjmlp 3y ago
    Unfortunately WinDev has decided all modern Windows APIs are based on COM. They aren't alone, Apple's XPC, Android and Fuchsia's Binder, and even Linux D-DBus, aren't much different. They have much better tooling though, something that Microsoft folks keep ignoring, so I understand where the pain comes from.
- Const-me 3y ago
  > How do you return an error that communicates "missing quote on line 42 character 200"? For that use case you gonna need some other piece of data besides the error code. Maybe another type like json_error_t in Jansson library. Or maybe a special strings, like the ones returned by sqlite3_errmsg() in SQLite library. > not something you should replicate in your own code if you have the choice I believe HRESULT, despite rather old, is still the best error handling strategy overall. Language-specific solutions like std::expected don’t work because all complicated software is written in multiple programing languages. For example, the entire ML ecosystem uses Python. 32-bit integers and strings are as language agnostic as you can possibly get. Enums don’t work because most non-trivial libraries have an unbounded number of possible error conditions. You made a parser library for some format, defined an enum containing all possible failures of the parser, but then a user tried to parse a file he doesn’t have read access to. The failures need to include disk I/O errors. Another user gonna parse their source file from a mounted network share, the failures returned from your parser now need to include TCP/IP errors.
- fweimer 3y ago
  Typically, you have a parser handle and can use that to query it about various aspects of its state. Here it would include line number, character offset, and byte offset. The type of error can be encoded in the error return value.