Jonathan Vollebregt jnvsor@gmail.com writes:
+static void reg_print_error(LSTATUS error_code) +{
- switch (error_code)
- {
case ERROR_SUCCESS:return;case ERROR_BAD_COMMAND:reg_message(STRING_INVALID_CMDLINE);return;default:{static const WCHAR error_string[] = {'%','0','5','d',':',' ','%','s',0};WCHAR *message = NULL;FormatMessageW(FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_IGNORE_INSERTS,NULL, error_code, 0, (WCHAR *)&message, 0, NULL);reg_message(STRING_ERROR);reg_printfW(error_string, error_code, message);LocalFree(message);return;}- }
+}
I don't think that's an improvement. There may be a need for generic Win32 error printing through FormatMessage for unknown codes, but I don't see why you'd want to route all errors through it. In particular, having to make up your own Win32 error codes only to convert them back to string ids is quite ugly.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2015-02-17 um 10:56 schrieb Alexandre Julliard:
I don't think that's an improvement. There may be a need for generic Win32 error printing through FormatMessage for unknown codes, but I don't see why you'd want to route all errors through it. In particular, having to make up your own Win32 error codes only to convert them back to string ids is quite ugly.
This kind of setup was originally my idea, so I might as well answer this question myself:
The basic plan is to let the advapi32 do as much of the error checking as possible and use the return value from the Reg* functions to tell the user what went wrong. There are a handful of failure modes that only apply to reg.exe and not advapi32 - in particular the currently unimplemented remote access and trailing backslashes.
The default path with FormatMessage is a fallback for unexpected errors. This could be an ERR if it is preferred, but an ERR won't be visible in the program output.
Stefan Dösinger stefandoesinger@gmail.com writes:
Am 2015-02-17 um 10:56 schrieb Alexandre Julliard:
I don't think that's an improvement. There may be a need for generic Win32 error printing through FormatMessage for unknown codes, but I don't see why you'd want to route all errors through it. In particular, having to make up your own Win32 error codes only to convert them back to string ids is quite ugly.
This kind of setup was originally my idea, so I might as well answer this question myself:
The basic plan is to let the advapi32 do as much of the error checking as possible and use the return value from the Reg* functions to tell the user what went wrong. There are a handful of failure modes that only apply to reg.exe and not advapi32 - in particular the currently unimplemented remote access and trailing backslashes.
I'm not sure that's a good idea either. It forces you to use generic error messages that are usually not very informative. It's better to do things in a way that allows printing more detailed errors in cases that are found to be confusing to users.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2015-02-17 um 13:43 schrieb Alexandre Julliard:
I'm not sure that's a good idea either. It forces you to use generic error messages that are usually not very informative. It's better to do things in a way that allows printing more detailed errors in cases that are found to be confusing to users.
Fwiw, native mostly just writes "SYNTAX ERROR", just internationalized, so you can't really check it in a script. There are some rare exceptions. The only one I remember is if you pass a negative number as REG_DWORD data.
My consideration was that reg.exe would duplicate some of the underlying function's logic and reg.exe would have to handle Reg* return values anyway.
-
Alexandre Julliard -
Stefan Dösinger