I'm new to the language (if we don't count that I did some stuff when was presented), I've been using vapor for a small personal project I did at the begining of the year, and I liked it, I liked it so much that at the end of august, I decided to migrate my migration of one of my projects (I was moving it from django to nestjs) to move it to swift. With the help of some AI, and since the nestjs, was pretty well typed, I've already reach a parity with nestjs. But I get some questions.
Recomendations for defining the error types with error codes
In Nestjs, I had a class for the Errors, that can get a code, some description (you can force that one code has a specific description in typescript), some context information (an object) and a cause which is optional.
What is the recommended way to declare errors? I saw that in some places, the Error is simply an enum, Since swift enums can accept more stuff, they can also add extra context, but there is a way to type it? Also, it can provide then some helpers, for example, stringify the error into some json (Is an example)
Get Stacktrace from error. How I can get a stackTrace to print it in the log when some error happen?
How I can get the working space folder in the machine (to remove it from the #file or to search other files in test?) right now I've got the following code to access to the files in the test:
There is a way to set a version into the target (inside of the package.swift) and this can be known by the application? right now I only have a small file that conatins the version, but I was thinking in having it in the Package.swift.
An error is simply anything that conforms to the Error protocol. It's commonly an enum, but can also be a struct or class, containing any information you might find useful.
Statically typed errors are possible now, see Specifying the Error Type. However, they have significant downsides which are often-overlooked.
They're not like adding types to parameters or return values. Strongly typed parameters and results impact the interface of your function, and leave you free to do anything side it that fits that interface. By contrast, strongly typed errors limit the implementation of your function, strongly constraining what you can do without making a breaking API change to your function's interface.
I'm not sure actually. I've only ever seen backtraces from fatal errors, not "regular" thrown/caught errors.
Not sure about specifying it in package.swift, but if you put it in Info.plist, you can access it via Bundle.main.infoDictionary!["CFBundleShortVersionString"] as! String (see this question).
Thanks, I already knew about the Error protocol, for the moment I will keep it like it is I think, maybe I can improve it later.
About the bundling resources into the swift package, it also works for non-mac os versions? As far as I knew Info.plist was a macos format (and If I remember correctly that had a binary version)
Also, if I wish to bundle the html, and js that webpack generates, should I add them into the package.swift? or is better to have it in a separate folder?