<yxhuvud>
threez: one thing I'd do is to not do `raise Exception.new("msg")`, but instead either create custom subclasses of exception or do `raise msg`. But the structure looks nice.
jmd_ has quit [Ping timeout: 240 seconds]
<FromGitter>
<threez> @yxhuvud thanks for your feedback . I did create an exception subclass so that all exceptions are of the type of the shard. Do have to make that explicit, it seems to work in the code?
<FromGitter>
<Blacksmoke16> Ahh, your subclass has the same name as the default one
<FromGitter>
<Blacksmoke16> that works as it'll resolve your type first, but is quite confusing imo. id say its more idiomatic to have the exception name represent what it is. otherwise its not much better than just using the default one
<FromGitter>
<Blacksmoke16> then maybe at least name it like `PDFError`?
<FromGitter>
<Blacksmoke16> if it represents an error from the underlying lib
hightower2 has joined #crystal-lang
<FromGitter>
<threez> @Blacksmoke16 understood. I think in most if not all cases it is a `ArgumentError` so I should really `Hpdf::Error < ArgumentError` and maybe have a special `Hpdf::HaruError < Hpdf::Error` for all errors created by the native lib. Like this? https://github.com/threez/hpdf.cr/pull/8
FromGitter has quit [Remote host closed the connection]
oprypin has quit [Quit: Bye]
oprypin has joined #crystal-lang
FromGitter has joined #crystal-lang
<FromGitter>
<Blacksmoke16> well are *all* exceptions really an argument error?
<FromGitter>
<Blacksmoke16> im never really sure which way to go, i.e. raise `ArgumentError` itself, or have an extension of it that you use. but either way the ones where you ensure something isnt less than 0 should deff be an argument error
<FromGitter>
<Blacksmoke16> but ones that come from haru shouldnt really as it could be the result of some error within the lib versus something the user themselves did
antoszka-r has joined #crystal-lang
<FromGitter>
<Blacksmoke16> looking thru the list i guess you could argue some of them are, but :shrug:
<FromGitter>
<Blacksmoke16> i sometimes also wish you could rescue based on a module included in an exception type. then it would be possible to rescue all exception from a specific lib no matter what parent exception type is
<yxhuvud>
Depends on the error I'd say. Is it a handling error (code time), rather than something that could happen during runtime? That is, I'd not set validation errors as argument errors even if it could potentially be relevant
<FromGitter>
<Blacksmoke16> Could also use a abstract exception class as an entry point to create specific subclasses based on the error code
<FromGitter>
<Blacksmoke16> E.g. ones that deal with validation would result in a validation error type, etc
<yxhuvud>
Yes. But creating overly many exception classes tend to not help all that much
<FromGitter>
<Blacksmoke16> for sure, deff dont need one type per error code
cameronr has joined #crystal-lang
cameronr has quit [Ping timeout: 252 seconds]
antoszka has quit []
antoszka-r is now known as antoszka
Sankalp has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
Sankalp has joined #crystal-lang
<FromGitter>
<threez> Maybe the IO related errors could be separated. Those maybe not related to the program but the env they are running in, so i will use *Error* for misuse and *IOError* for the other cases
<FromGitter>
<threez> @Blacksmoke16 btw, thanks for your book about crystal
jmdaemon has joined #crystal-lang
<FromGitter>
<Blacksmoke16> np!
<FromGitter>
<stellarpower> Wow, I didn't know there was a book.
<FromGitter>
<stellarpower> Nice! The online docs aren't enough for me ⏎ I've just done my first C wrapping and it'd be good to have something that walks you through it more than a reference to each keyword and feature.
<FromGitter>
<Blacksmoke16> contributions to the online docs would also be very welcome ;)
<FromGitter>
<stellarpower> On that note, I'm getting a segfault and bacltrace when I run, it was fine before but now some minor modifications and it's not happy. Is there a way of differentiating if the segfault happened on the C side or if it was once crystal was cleaning up after the call?
<FromGitter>
<Blacksmoke16> prob could be a multitude of things?
Sankalp has quit [Ping timeout: 268 seconds]
Sankalp has joined #crystal-lang
<FromGitter>
<stellarpower> It all looks a bit strange to me.
<FromGitter>
<stellarpower> Can it be as I rebuild the C library my share is using a cached build and not rebuilding the dependencies?
<FromGitter>
<Blacksmoke16> iirc you can build with a `-v` flag to see the linker command
<FromGitter>
<stellarpower> Actually it looks like just opening the built binary in Qt Creator lets me debug it in GCC, both the C and the Crystal, so that should help
<FromGitter>
<stellarpower> Hate printf debugging
<FromGitter>
<stellarpower> It looks like some globals are being cleaned up between calls into the library
notzmv has quit [Ping timeout: 268 seconds]
<yxhuvud>
Are you keeping references to them? Otherwise there is a risk the GC will collect them
<FromGitter>
<stellarpower> C globals I mean
<FromGitter>
<stellarpower> The original was a bit of a mess IMO, everything was in the main function so it's been brittle tearing that out
<FromGitter>
<stellarpower> I had forgotten how onerous C is
<FromGitter>
<stellarpower> But it seemed to be okay before so am not sure what changed
<FromGitter>
<stellarpower> Ah wait got it
<FromGitter>
<stellarpower> Must've just been a fluke before, something was not-so-transparently bringing back a pointer into an array, albeit of globals, on the stack
<FromGitter>
<stellarpower> Fab, got there in the end, thanks guys
<FromGitter>
<stellarpower> Eugh, C is not fun, I want my variadic templates back
<FromGitter>
<stellarpower> Although the Crystal side of integrating it has been pretty nice so far, so good work in that.
<FromGitter>
<stellarpower> Only thing now is that my `finalize` doesn't seem to be being called.
<FromGitter>
<stellarpower> Are there circumstances when it isn't ever run on an instance of a class?
<FromGitter>
<Blacksmoke16> if the GC never runs
<FromGitter>
<stellarpower> So if the program exits it could just abandon the memory and let the OS clean it up?
<FromGitter>
<Blacksmoke16> yea
<FromGitter>
<stellarpower> Hmm
<FromGitter>
<stellarpower> I think I remember reading, is the only option presently to force myself to clean up?
<FromGitter>
<stellarpower> The idea of not having a guaranteed destructor makes me feel a bit uneasy, but I guess even if it wrre implemented, for a garbage-collected language it doesn't make an enormous amount of sense anyway, as you can't guarantee the object lifecycle anyway