| Age | Commit message (Collapse) | Author |
|---|
|
Some of these unwraps are fine to stay, mostly those that deal with
locks - in this case, crashing the program if something goes wrong is
probably fine.
However, we also had a lot of other places where we panic'd on errors,
even though we really shouldn't have. For example, an invalid zip file
would bring down the whole scanner. In this case, we now use proper
Result<>s and we log the error.
Some places stay with unwrap() for now, mainly the code that is rare and
obvious when it goes wrong - such as an overflow in input values. It
could be made nicer, but it is not a priority for now.
Some unwraps() have been changed to expect() to signal why they
shouldn't fail.
|
|
This does currently not work yet, as we cannot call .finish() on dyn
Aggregator. This needs to be adjusted.
However, this provides the basic infrastructure for producing sorted
output, including the required command line parsing.
|
|
It's kinda silly to have new() be generic when all it does is box the
objects anyway. It only makes code harder to write, as we cannot unify
the types to call Pipeline::new(), and instead we have to rely on
calling Pipeline::new() in the branches themselves.
It's not the biggest issue when we only have different formats, but at
some point we might want to add different aggregators as well (like a
sorting one or a counting one), so it would be bad if we suddenly had to
add all those branches.
This fix changes that, and we can build the pipeline piecewise by
having a Box<dyn Format> around, allowing us to combine it freely with
any Box<dyn Aggregator>.
|
|
|
|
|
