Survive a missing UniProt proteome catalogue at startup - #2700
Open
trishorts wants to merge 2 commits into
Open
Conversation
LoadAvailableProteomes read the proteome catalogue with no guard, and SetUpGlobalVariables runs in the MainWindow constructor and in Program.Main outside any try/catch. So anything that stopped the file being read took the whole program down at launch rather than costing one GUI feature. That was survivable while mzLib answered a missing file with null; it is not once it throws (smith-chem-wisc/mzLib#1126, which stops ProteinDbRetriever reporting every failure as null). The file is shipped beside the executable, but DataDir does not always resolve there: a Program Files install uses %LOCALAPPDATA%\MetaMorpheus, and --customDataDir pointed at a folder that already exists skips CopyFilesRecursively entirely, so in both cases Proteomes\ can simply be absent. The catalogue is a convenience for the "Download UniProt Database" window, not a prerequisite for searching, so failing to read it now degrades to an empty dictionary and a message on the console. Empty rather than null is deliberate: DownloadUniProtDatabaseWindow enumerates AvailableUniProtProteomes and calls FirstOrDefault on it with no null check, so the old null was already a latent NullReferenceException the moment that window was opened. This fixes that too. The catch is deliberately broad — absent, wrong extension, truncated, locked, unreadable all have the same consequence for an optional catalogue, and none of them is worth refusing to start over. Tested by hiding the catalogue and asserting startup still completes with a non-null empty dictionary; verified the test fails without the guard.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #2700 +/- ##
==========================================
- Coverage 93.28% 93.28% -0.01%
==========================================
Files 214 214
Lines 21795 21803 +8
Branches 4078 4079 +1
==========================================
+ Hits 20331 20338 +7
Misses 910 910
- Partials 554 555 +1
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Companion to smith-chem-wisc/mzLib#1126, and useful on its own.
The problem
GlobalVariables.LoadAvailableProteomesread the proteome catalogue with no guard:SetUpGlobalVariablesis called from theMainWindowconstructor and fromProgram.Mainoutside any try/catch, so anything that stops that file being read takes the whole program down at launch rather than costing one GUI feature.That was survivable while mzLib answered a missing file with
null. It is not once it throws — which is what mzLib#1126 does, stoppingProteinDbRetrieverfrom reporting every failure (bad ID, unsupported format, UniProt outage, missing file) as the samenull.The file is shipped beside the executable, but
DataDirdoes not always resolve there:%LOCALAPPDATA%\MetaMorpheus, which an upgrade can leave incomplete;--customDataDirpointed at a folder that already exists skipsCopyFilesRecursivelyentirely (SetUpDataDirectoryonly copies when the directory is absent), soProteomes\is simply not there.The fix
The catalogue is a convenience for the "Download UniProt Database" window, not a prerequisite for searching. Failing to read it now degrades to an empty dictionary and a console message.
Empty rather than null is deliberate, and fixes a second latent bug.
DownloadUniProtDatabaseWindowenumerates this property and callsFirstOrDefaulton it with no null check:so the old
nullwas already aNullReferenceExceptionwaiting for someone to open that window.The
catchis deliberately broad: absent, wrong extension, truncated, locked and unreadable all have the same consequence for an optional catalogue, and none is worth refusing to start over.Merge order
This is forward- and backward-compatible — it handles both the current
nulland the post-#1126 throw — so it can merge before or after the mzLib release, and before the version bump. Merging it first is safest.Tests
TestStartUpSurvivesAMissingProteomeCataloguehides theProteomesdirectory, assertsSetUpGlobalVariables()does not throw, and asserts the property is non-null and empty. Verified it fails without the guard (Expected: not null / But was: null) and passes with it.TestProteomeCatalogueIsReadWhenPresentcovers the normal path. All 9 tests in the fixture pass.