Usando numeri di errore che funzionano solo su server a 64 bit: una cattiva idea?

I would like to have a [...] way of creating unique error numbers, across projects and across developers.

IMHO che è la cattiva idea. È necessario evitare la necessità di disporre di un numero di errore univoco globale oltre i limiti del progetto. Questo è un requisito globale che non è possibile soddisfare non appena è necessario aggiungere componenti di terze parti e, a lungo termine, sarà anche difficile stabilire una simile regola tra molti progetti e molti sviluppatori. Quindi, è meglio progettare il tuo sistema in modo da poter gestire localmente i tuoi numeri di errore, questo ti darà molta più flessibilità e non accoppierà i progetti non correlati con le regole ostruttive.

In che modo i tuoi singoli progetti gestiscono i loro numeri di errore, quindi sono a loro, ma sono abbastanza sicuro che troveranno un modo per mantenerli al di sotto dei 32 bit.

This works brilliantly on 64 bit machines, but the resulting integer is too large for 32 bit computers.

In realtà, i computer a 32 bit sono in grado di gestire numeri a 64 bit. OK, quindi l'aritmetica a 64 bit potrebbe richiedere alcuni cicli di clock aggiuntivi su una macchina a 32 bit, ma è improbabile che ciò sia significativo. (O anche rilevanti ... nel tuo caso d'uso.) Ad esempio, i set di istruzioni x86 hanno istruzioni aritmetiche a 64 bit.

Does that make this a bad idea?

Non per il motivo che hai dichiarato. potrebbe essere una cattiva idea per altri motivi. (Per esempio, se ci sono più informazioni che puoi codificare in 64 bit, il tuo schema si rompe.)

How common are 32 bit servers, and do we expect them to slowly disappear completely?

Sono ancora comuni e probabilmente continueranno all'infinito. Se in realtà non è necessario più di 2 ^ 30 di spazio di indirizzamento per un'applicazione, i puntatori a 32 bit occupano meno memoria dei puntatori a 64 bit ... quindi un'architettura di modello "piccola" sarà più efficiente, ecc.

Sono d'accordo anche con @DocBrown. I numeri di errore introducono tutti i tipi di problemi propri ... inclusa la tendenza a mostrare sequenze di cifre inintelligibili agli utenti finali. L'approccio human friendly è un'eccezione ben denominata e un messaggio di eccezione intelligibile / informativo.

L'altra osservazione è che la tua domanda mostra i segni di "ottimizzazione prematura". È probabile che l'impatto reale sulle prestazioni dell'ottimizzazione proposta sia insignificante, e forse anche troppo piccolo per essere misurato in un'applicazione reale in esecuzione in condizioni realistiche.

Il consiglio standard è di non sprecare il tuo tempo con questo genere di cose ... a meno che tu non abbia prove concrete (dalla misurazione della tua applicazione) che 1) lo sforzo di ottimizzazione sia garantito, e 2) questo particolare bit di codice abbia un impatto significativo sulle prestazioni generali della tua applicazione.

Perché non utilizzare un tipo di dati stringa per il codice di errore anziché un numero? Ciò consentirà di archiviare un codice di grandi dimensioni senza problemi di dimensioni integer. Anche se il codice di errore sembra un numero, a meno che il design non stia chiamando aritmetica con esso, allora non è un numero, quindi dovrebbe essere davvero un tipo di dati stringa.

Sono anche un po 'preoccupato per questo metodo per i codici di errore. I codici di errore devono essere progettati nell'applicazione, elencati nella documentazione e, se attivati, essere prevedibili. Se il codice attiva un'eccezione, dovrebbe essere lo stesso codice di errore con gli stessi input. Tuttavia, questo design utilizza un evento casuale per identificare l'errore, né indica dove nel codice si sta verificando l'eccezione, solo chi ha scritto il codice e quando è stata attivata l'eccezione.

Questa è una pessima idea.

Vuoi "facile e memorabile". Hai già scoperto che la tua soluzione non è facile.

1. Stai valutando la possibilità di farti rientrare in un angolo a 64 bit per risolvere questo problema.
2. Che cosa succede quando Mary Smith e Mike Simpson si uniscono al team?
3. Come puoi garantire l'unicità della parte numerica?
4. Ogni volta che ci si affida alla memoria del programmatore, si aggiunge ulteriore carico cognitivo ai programmatori. Sarà una distrazione dalla codifica o verrai dimenticato
5. Stai reinventando la ruota. I GUID esistono già e possono essere convertiti in numeri interi a 128 bit.
6. Le macchine a 32 bit possono gestire perfettamente i numeri a 64 bit.
7. Le librerie di terze parti non seguiranno il tuo schema.

Stai risolvendo il problema giusto? Qual è il vantaggio dei numeri di errore univoci? Quanto è importante questo requisito per i tuoi clienti?

Se devi davvero andare in quel modo (a volte è un requisito imposto dai "sopra-sopra").

potresti creare lunghi codici stringa espliciti, ad esempio: ERROR__PROJECT_COULD_NOT_CREATE_THAT_UBER_IMPORTANT_RESOURCE

e tramite una funzione di hashing deterministica trasformalo in un numero intero a 32 bit.

Idealmente per essere globali dovresti probabilmente avere una sorta di repository centralizzato in cui si possa inserire il codice stringa e ottenere l'hash per esso. Lo stesso repository potrebbe anche generare codice da includere nel progetto in modo che il codice possa quindi fare riferimento alla costante di stringa anziché a quel brutto numero magico. Essendo generato centralmente, tutti i progetti includevano la stessa lib / header e ottenevano i codici. Anche il repository sarebbe in grado di avvertire di possibile (per quanto improbabile possa essere) la collisione dell'hash.

Intendiamoci, non penso che questa sia la soluzione migliore, sono totalmente d'accordo con Doc Brown qui e faccio un passo indietro verso questa intera esigenza. Solo che non farebbe male ad essere bloccato in questa situazione.

Lascia che un database crei il tuo numero univoco per te - registra l'errore in un dl sql e il tuo problema è risolto. Includi informazioni sull'applicazione (ovvero quale app ha riscontrato l'errore) e Bob è tuo zio.

Il mio consiglio è di migrare il codice al sistema operativo e ai processori a 64 bit. Quando acquisti nuovi PC, laptop o server vai a 64 bit. Attualmente Microsoft non ha l'edizione Server con 32 bit, ha solo Windows Server 2008 e 2012 a 64 bit.

Il motivo alla base è il 19 gennaio 2038 la data dei computer a 32 bit verrà reimpostata al 1 ° gennaio 1970, fare riferimento al link seguente.

link

Se la tua applicazione esegue l'elaborazione degli interessi sui prestiti il 13 gennaio 2038, il tuo computer a 32 bit reimposta automaticamente la data a gennaio 1970 e la società potrebbe avere la possibilità di pagare interessi ai clienti.

Di nuovo, avrai una domanda quando la data del SO a 34 bit verrà ripristinata. Ci vorranno alcuni miliardi di anni per resettare.

Due problemi qui:
1) "codici di errore univoci tra prodotti. Idea BAD come altri hanno già indicato 2) "Server a 32 bit. Ancora quelli esistono ancora? E in tal caso, pensi davvero che le persone che li gestiscono vorranno pagare per il tuo prodotto se non hanno ritenuto opportuno aggiornare il loro hardware e sistemi operativi nel dura diversi anni?