[[post_data {
    "author" : "KyMAN",
    "since" : 20211202,
    "version" : 20220306
}]]
# Gestión de errores

La gestión de permisos se convirtió en un problema para el desarrollo pues originalmente se tomaba
como referencia de código de error un valor numérico entero cuyos bits indicaban cada uno de los
errores que se estaban gestionando de forma global, no parcial, es decir, se hacía un análisis de
los errores en su conjunto y se retornaban todos los que hubieren, pero con el diseño de una
aplicación relativamente grande donde una tupla de datos constaba de alta cantidad de datos
simultáneos, una gestión de errores global basada en un valor numérico entéro empezaba a ser
inviable por el hecho de la limitación de los bits del mismo, donde si usamos un tipo "intenger" o
"Int32" tenemos 32 bits, donde hasta el bit 29 es de uso seguro; mientras que si usamos un tipo
"bigint" o "Int64", este valor pasaba por los lados enteros y decimales de la mantisa de 64 bits
dando consigo hasta 64 bits, donde sólo 58 serían de uso seguro.

Para evitar este error habría que pensar en otros métodos que sean de uso global o general, donde no
podía haber Arrays pues éstos no existen en todos los lenguajes como pueden ser los SQL, salvo que
tengan las funciones de JSON; tampoco múltiples salidas de error lo cual crea una indeterminación a
la hora de trabajar con los programas de forma automátizada, además de obfuscar mucho el código
resultante; los trabajos binarios directos (DAT y demás) les pasa lo mismo que a los Array.
Finalmente, con la idea de los bits y los Array, se puede usar un String y generar un alfabeto en
base a una base de trabajo.

Siguiendo dicha conclusión, Base64 es el estándar más sencillo de seguir, aunque éste permite
caracteres que pueden dar lugar a confusión, como pueden ser la I (i latina mayúscula), l (ele
minúscula) y 1 (uno); o O (o mayúscula) o 0 (cero); etc. La opción más viable para esquivar este
problema sería el uso de una Base58 pero ésta rompería su estructura binaria (Potencia base 2) con
lo que el factor bit a bit no podría existir, así que se decidió sacrificar esta idea en beneficio
de la seguridad, facilidad, rendimiento y legibilidad por la Base64.

La Base64, en caracteres individuales, no es más que conjuntos de 6 bits (2 elevado a 6, que son los
64 caracteres). Hay que tener cuidado con los alfabetos pues Base64 puede contener 65 caracteres si
contamos el caracter de relleno contra Bytes (El "=").

Con esta idea en mente, tenemos un alfabeto de 64 caracteres que forman conjuntos de 6 bits a los
cuales se les llamará, a partir de ahora, Hexa (Hexas en plural).

> [[! note NOTA]]: El alfabeto puede ser alterado completamente a excepción de su longitud, y para
que funcione correctamente, ha de tener todo caracteres diferentes. Hay que tener especial cuidado
con caracteres especiales que pueden conformarse por más de un caracter (Caracter de escape y cadena
o consecución de bytes del nuevo caracter). Estos caracteres especiales constarán como más de uno en
algún lenguaje como JS o PHP, y han de tener especial cuidado cuando cambia la codificacion del
String pues puede dar lugar a resultados inesperados.

Por defecto, los errores han de darse en String por capacidad de longitud e interpretación de
bloques binarios a modo de Array a partir de los caracteres, sin embargo, la longitud máxima de uso
ha de determinarse a partir de tres condicionantes:

- La longitud máxima de tipo en el lenguaje más restrictivo.
- La longitud por tamaño de memoria máximo para establecer.
- En base al punto anterior, si es de tamaño fijo o dinámico.

> [[! note NOTA]]: En este caso, el lenguaje más restrictivo viene siendo SQL Server en Transact
SQL, que viene siendo 8000 caracteres.

> [[! important IMPORTANTE]]: No se usarán tipos text, ntext ni nvarchar ni equivalentes por el
hecho de que trabajan longitudes no dadas para mover caracter a caracter, además, los tipo text y
equivalentes se almacenan externamente al BAK de la base de datos a modo fichero.

En este caso se pondrá 512 caracteres a modo de 512 Hexas, 384 bytes, que serán de longitud
variable. Esto dará desde 0 a 3072 posibles errores globales.

> [[! note NOTA]]: Aunque no es una práctica muy habitual en conjuntos grandes de datos, se
determinó hacer un sistema de gestión de errores global y no parcial por el hecho de que permite al
usuario final determinar o corregir, de forma mucho más rápida y eficiente el conjunto de errores
que puediere tener, así como una gestión más profunda de los errores que puedan surgir o haber.

## Métodos requeridos

Para empezar, hemos de tener en cuenta que todo se trabajar en base a String pues será la base de
trabajo para poder moverse en Base64, aunque eso no implica que podamos trabajr bloques de 29 bits
íntegramente como enteros, lo que permite trabajar tradicionalmente a nivel binario y con un
resultado String en Base64. Para lograr este objetivo es necesario desarrollar las siguientes
funciones básicas:

> [[! note NOTA]]: Dependiendo del lenguaje puede que hagan falta más funciones o métodos para
trabajar con dicho sistema. Dichas funciones pueden detallarse más adelante dependiendo del
lenguaje.

### to_string

Este método convierte un valor numérico en uno String en Base64 según los Bits del número en
fragmentos de Hexas. Simplemente requiere la entrada del valor numérico y una salida que sería el
valor String Base64 equivalente. La conversión se dará a partir del alfabeto que esté configurado.

### to_integer

Este método convierte un valor String, el cual se espera que sea Base64 con el alfabeto existente en
la configuración actualmente, y lo convierte en un valor numérico entero de un máximo de 29 bits, a
partir de dichos bits puede dar lugar a errores, excepciones y problemas inesperados que pueden
variar según el lenguaje y entorno donde se esté ejecutando.

### bitwise

Este método permite hacer un desplazamiento de X bits dados tanto a la izquierda como a la derecha
sobre el valor String Base64 dado. Para identificar la dirección del desplazamiento se usarán
valores enteros positivos y negativos.

> [[! note NOTA]]: La comprobación de este método ha de ir ayudado del método to_integer, e incluso
de métodos que visualicen los binarios pues el alfabeto puede ser muy abstracto de ver.

### has

Este método determina si hay o no error a partir de un código de error String base64. Se establece
un método que determine ésto por el hecho de la complejidad de interpretar visualmente un código de
este tipo así como la posibilidad de poder configurar un alfabeto Base64 para el mismo que pueda
variar, lo que dificulta saber si ésta posee errores o no.

### set y/o join

Estos métodos no son más que el mismo pero sobrecargados, pero se establecen como separados por
lenguajes que no posean sobrecargas, como es el caso de los SQL. Básicamente es un método que
permite añadir un código de error al código de error actual. En caso de no haber un código de error
inicial, éste lo creará como si no hubiese errores y unirá el nuevo código en la posición dada.
Dicho método puede funcionar como OR o como AND, incluso como una pseudomezcla de los mismo mediante
los atributos que posee que son los siguientes:

- **code**: Código de error original.
- **error**: Código que se quiere concatenar.
- **bit**: Bit de posición donde se concatenará.
- **length**: Bits del código de error original que se pasarán a 0 desde la posición dada en el
elemento anterior, lo que permite hacer un pseudo AND.

> [[! note NOTA]]: Si se da una posición "bit" superior a la longitud del código de error original,
éste rellenará posiciones hasta llegar al bit donde se intgrará el nuevo código de error.

La función "set" estaría orientada a concatenar al código original un código de error en formato
numérico entero de hasta 29 bits; mientras que la función "join" estaría orientada a concatenar al
código original un código de error en formato String Base64. Ambos serán set en los lenguajes que
admitan sobrecarga o métodos/funciones flexibles como JS.

## Punto de aplicación

Por dependencia, esta librería ha de ir al principio de todo, y hay que tener en cuenta que ésta
consume otras librerías como Settings, por lo que habría que hacer una librería de elementos comunes
iniciales, luego ésta, y luego la librería de arranque, todo ello, sin incluir librerías intermedias
que puediere haber según lenguaje.

## Dirección del String Base64

La dirección del String Base64 será de derecha a izquierda para tener la creación del mismo de forma
natural a la de un valor numérico entero.

[[html_data {
    "title" : "Gestión de errores - AnP",
    "url" : "https://anp.k3y.pw/es/dev/errors.html",
    "author" : "KyMAN",
    "since" : 20211202,
    "version" : 20220306,
    "key_words" : "anp,attach,play,attach&play,errores,gestión",
    "description" : "Gestión de errores del AnP.",
    "project" : "AnP",
    "logo" : "https://anp.k3y.pw/images/anp.png",
    "language" : "es"
}]]
