新しい投稿

検索

記事
· 2024年12月9日 1m read

¿Cómo generar un error personalizado?

#ヒントとコツ #ObjectScript #Caché #Ensemble #InterSystems IRIS #InterSystems IRIS for Health

Rúbrica de preguntas frecuentes de InterSystems

 

Si queréis generar un error personalizado arbitrario en un bloque TRY, podéis pasar una excepción con un throw de la siguiente manera. En el siguiente ejemplo, se genera un error personalizado si el valor de Stcount es menor que 1.

Class User.Test
{

ClassMethod ExceptionTest()
 {
    try
    {
      // : some codes
      if (Stcount<1) {
          throw ##class(%Exception.General).%New("User-defined error", "5001", "location", "Data at location error")
          // User-created errors are 5001 and above
      }
    }
    catch ex
    {
      write "Errors #", ex.Code, ": ", ex.Name, " : ", ex.Location, " ", ex.Data
      return
    }
 }
}

En el ejemplo anterior, si Stcount es menor que 1, aparecerá un error como el siguiente:

USER>do ##class(User.Test).ExceptionTest()
Error #5001: User-defined error: Data at location error

Para más información, consultad la siguiente documentación:
Comando _THROW de ObjectScript

Si deseáis crear un código de estado arbitrario, haced lo siguiente:

USER>set st = ##class(%SYSTEM.Status).Error(5001,"This is a user-defined error")

USER>zwrite st
st="0 "_$lb($lb(5001,"This is a user-defined error",,,,,,,,$lb(,"USER",$lb("e^zError+1^%SYSTEM.Status.1^1","e^^^0"))))/* Error #5001: This is a user-defined error */
USER>do $SYSTEM.Status.DisplayError(st)

Error #5001: This is a user-defined error
ディスカッション (0)1
続けるにはログインするか新規登録を行ってください
InterSystems公式
· 2024年12月9日
Open Exchange

Nouvelles et prochaines fonctionnalités de Git intégré

#ソース管理 #Embedded Git #Git #相互運用性 #オープンソース #スタジオ #VSCode #InterSystems IRIS #InterSystems公式 #Open Exchange

Cela fait un moment que je n'ai pas publié d'article sur Embedded Git sur la Communauté des développeurs, et j'aimerais faire le point sur l'énorme quantité de travail que nous avons accompli cette année et sur la direction que nous allons prendre ensuite.

Contexte

Si vous créez des solutions sur IRIS et que vous souhaitez utiliser Git, c'est parfait ! Utilisez simplement VSCode avec un dépôt git local et transmettez vos modifications sur le serveur : c'est aussi simple que cela.

Mais que se passe-t-il si :

  • Vous collaborez avec d'autres développeurs sur un environnement de développement partagé et distant et que vous souhaitez éviter de vous marcher sur les pieds en modifiant le même fichier en même temps.
  • Vous utilisez des éditeurs basés sur le portail de gestion pour l'interopérabilité ou la veille économique et vous souhaitez un contrôle de source simple pour votre travail, même dans un conteneur local.
  • Vous utilisez toujours Studio pour certaines choses et/ou revenez occasionnellement à cet endroit depuis VSCode ; ou votre équipe n'a pas encore complètement adopté VSCode, et certains membres de l'équipe veulent toujours utiliser Studio tandis que d'autres utilisent VSCode.
  • Vous travaillez sur un ensemble de projets distincts en même temps dans le même espace de noms - par exemple, plusieurs packages définis à l'aide du gestionnaire de packages InterSystems - et vous souhaitez simplement travailler avec tous à partir d'une seule vue d'édition isfs (plutôt qu'avec un ensemble de projets distincts) avec les modifications suivies automatiquement dans le dépôt git local approprié.

Dans tous ces cas, vous avez vraiment besoin d'un contrôle de source intégré. Vous avez peut-être entendu parler de « contrôle de source côté serveur » ou de « crochets de contrôle de source » - c'est la même chose, et cela signifie qu'il existe un comportement de contrôle de source cohérent dans tous les éditeurs, à la fois IDE et éditeurs graphiques, sur une instance IRIS. Tout cela fonctionne avec un référentiel de contrôle de source colocalisé avec votre instance IRIS, qui peut se trouver sur un serveur distant, votre propre machine ou même dans un conteneur.

Si vous souhaitez vous lancer dans le contrôle de source intégré à l'aide de Git, Embedded Git (https://github.com/intersystems/git-source-control) est l'endroit idéal pour commencer. Ce produit n'est pas pris en charge par InterSystems, mais il bénéficie d'un soutien important de la part de mon équipe (Application Services) au sein d'InterSystems et d'une large communauté d'utilisateurs. Les PR et les problèmes GitHub sont toujours les bienvenus, et nous surveillons l'activité de la communauté des développeurs (en particulier à l'aide de la balise relativement nouvelle « Embedded Git »).

Embedded Git en 2024

Au début de l'année, j'aurais recommandé Embedded Git aux utilisateurs plus techniques déjà à l'aise avec Git et prêts à entrer dans les détails en cas de besoin. Maintenant, je le recommande sans réserve à tout le monde. Pour vous donner une idée des efforts que nous avons déployés pour l'outil et des progrès fous que nous avons constatés en 2024, voici un graphique de notre volume de validation au cours des dernières années :

Si vous voulez voir ce que nous avons fait, vous pouvez consulter les versions ou notre journal des modifications, mais voici un résumé des points forts :

  • En juillet, nous avons ajouté un « mode de base » décrit ici avec une opération « Sync » qui simplifie un flux de travail pull/commit/rebase/push que nous recommandons en général, mais surtout pour les personnes moins familiarisées avec Git.
  • Dans plusieurs versions, nous avons fait en sorte que les opérations git pull et checkout - en fait, tout ce qui modifie l'état du dépôt Git - se synchronisent de manière transparente dans IRIS afin que tout soit maintenu à jour sans avoir à recharger de force toute la base de code.
  • Notre version de septembre a rendu très facile la configuration d'une connexion isfs en téléchargeant un fichier d'espace de travail VSCode à partir du portail de gestion.
  • Notre version de novembre a permis de configurer bien plus de choses via la page des paramètres de l'extension plutôt que de devoir exécuter des commandes dans le terminal et a ajouté une résolution intelligente des conflits de fusion pour les deux cas d'utilisation les plus courants (quasi garantis) dans un contexte d'interopérabilité.
  • En plus de tout cela, nous avons résolu des dizaines de bugs mineurs et de problèmes d'utilisabilité, simplifié la navigation via le portail de gestion et ajouté de nombreuses fonctionnalités plus petites pour rationaliser les cas d'utilisation d'interopérabilité et la collaboration entre plusieurs espaces de noms spécifiques aux développeurs sur une instance distante partagée (ce que nous considérons et recommandons comme une approche courante).

À venir

Notre prochaine version (2.8.0), attendue dans les deux prochaines semaines, inclura une fonctionnalité sur laquelle nous travaillons depuis des mois : la « décomposition de la production ». La production d'interopérabilité est généralement contrôlée à la source sous forme de fichier unique, ce qui entraîne des problèmes de concurrence car une seule personne peut modifier la production à la fois. Il existe également des conflits de fusion quasi garantis dans les environnements de développement partagés, et bien que nous puissions les résoudre de manière intelligente, ils continueront probablement à se produire dans certains flux de travail de branche. Avec la décomposition de la production, chaque hôte métier (service, processus ou opération) est représenté dans le contrôle de source sous forme de fichier unique. Si vous souhaitez essayer cela, faites-le nous savoir !

Nous allons maintenir la dynamique d'Embedded Git jusqu'en 2025, en nous concentrant sur des méthodes d'authentification supplémentaires et sur la prise en charge d'autres modèles de déploiement courants. Vous pouvez voir le plan approximatif dans notre jalon H1 2025 (qui comprendra quelques versions ; nous publions généralement des versions mineures tous les mois et des versions correctives selon les besoins pour les corrections de bogues clés).

Si vous souhaitez en savoir plus ou suivre le développement au fur et à mesure, nous organisons une réunion hebdomadaire des parties prenantes le vendredi à laquelle vous serez le bienvenu. Cela sert également en quelque sorte de « heures de bureau » pour Embedded Git en général. N'hésitez pas à m'envoyer un message avec votre adresse e-mail et je vous inviterai.

ディスカッション (0)0
続けるにはログインするか新規登録を行ってください
ダイジェスト
· 2024年12月9日

Publications des développeurs d'InterSystems, semaine Décembre 02 - 08, 2024, Résumé

#開発者コミュニティ公式 #ダイジェスト
Décembre 02 - 08, 2024Week at a GlanceInterSystems Developer Community
ダイジェスト
· 2024年12月9日

Nuevas publicaciones en la Comunidad de InterSystems, 2-8 diciembre

#開発者コミュニティ公式 #ダイジェスト
Artículos
Anuncios
Preguntas
2-8 diciembreWeek at a GlanceInterSystems Developer Community
質問
· 2024年12月9日

Unstable Nginx with "stable" webgateway

#Web Gateway #InterSystems IRIS

So, we have docker image webgateway-nginx, marked as latest-em, which means supposed to be extended maintenance

$ docker run -it --entrypoint bash containers.intersystems.com/intersystems/webgateway-nginx:latest-em

root@9ca3373fe980:/# /opt/nginx/sbin/nginx -V
nginx version: nginx/1.21.5
built by gcc 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04) 
built with OpenSSL 1.1.1n  15 Mar 2022
TLS SNI support enabled
configure arguments: --prefix=/opt/nginx --with-pcre=/opt/pcre-src --with-zlib=/opt/zlib-src --with-openssl=/opt/openssl-src --with-http_gunzip_module --with-http_ssl_module --with-http_v2_module --add-module=/opt/nginx-src/csp

root@9ca3373fe980:# /opt/webgateway/bin/CSPnsd -h    

InterSystems CSP - Network Service Daemon

   Version 2024.1.2.398.0 Gateway Build 2401.1845 (Multi-Threaded)

Gives nginx version 1.21.5, version that lost support more than 2 years ago

And to add a bit more

Versioning Scheme

The open-source NGINX project maintains two branches: mainline and stable.

  • mainline: Mainline is the active development branch where the latest features and bug fixes get added. It is denoted by an odd number in the second part of the version number, for example 1.21.0.
  • stable: Stable receives fixes for high‑severity bugs, but is not updated with new features. It is denoted by an even number in the second part of the version number, for example 1.22.0. The stable branch never receives new functionality during its lifecycle and typically receives just one or two updates, for critical bug fixes.

So, why EM version of webgateway got unstable version of Nginx, which is anyway outdated for more than 2 years?

ディスカッション (0)2
続けるにはログインするか新規登録を行ってください