Feature request: error codes

It would be super-useful if the major system calls could return better error codes. I’ve go some URL problems at the moment and the current true/false for whether stuff worked is pretty rubbish. Maybe it’s an SSL certificate problem, maybe it’s a DNS problem … who knows :wink:

Perhaps input and output streams could have something like

/** Returns as much information as available about the error that occurred with the connection */
Result getError(); 

I could live with a platform dependant string as a result - it’s not like the errors can be solved programmatically - but they sure would help our support!

Yep - I introduced the Result class a few years ago with the aim of it becoming a replacement for all the old bool return values, but updating them all has been one of those tasks that just never seems to make it to the high priority list!

1 Like

It’s pretty high up my list :wink:

I can send you a patch shortly for the Windows implementation of WebInputStream … maybe I’ll extend it to cover the Mac though I migrated the Mac stuff to use LibCurl because of some other bug.

Thanks - patches certainly help to make us get things done!

I’m going to deliberately do an awful job of it too.

It’ll make you angry enough to do it properly :wink:


Error codes in C++?

Ehrr… “Semantically rich return values”? :sweat_smile:

1 Like

Incidentally - Windows 10 with JUCE seems very permissive - the last two connections succeeding looks like a real problem to me. Substantial security flaw unless I’m missing something…

IMHO, that’s what exception are for. If you have errors, that’s the way you usually unroll your stack until someone can do something about it (and probably stop processing).

JUCE doesn’t really do that anywhere - which is a design decision love it or hate it…

1 Like

Well, having added in result codes and sent a test app to my (entirely windows) users who have connection difficulties I’ve discovered two things:

  • Most users had a different problem. So far I’ve had ERROR_INTERNET_SECURITY_CHANNEL_ERROR, ERROR_INTERNET_CANNOT_CONNECT and ERROR_INVALID_USER_BUFFER (!!) trying to connect to our servers.
  • A mysterious error code 18 trying to connect to https://www.google.com/ using the URL class - the http:// connection worked fine.
  • The error reporting code needs to report the OS function that the error occurred with to make it easier to troubleshoot.

So back to the drawing board with these ‘semantically rich return values’…

(Actually - just remembered my Mac users are using LIBCURL. It was a fight to compile and link CURL for Windows otherwise things might be easier…)