Má Nette\Web\HttpResponse vyhazovat výjimky?

Obecně jsou mi výjimky sympatičtější, ale v tomto případě bude nejspíš lepší varování, které se při vývoji přetočí ve výjimku. Další hlavičky, u kterých by nenastavení mohlo vadit, jsou třeba Content-type a Content-lang, ale pro tu první existuje zvláštní metoda, která by mohla reagovat odlišně.

Nemůžu přijít na rozumný příklad, kdy by mi vadilo vyhození výjimky při neúspěšném přidání hlavičky. Na jednu stranu nemusí být na produkčním serveru nutné kvůli tomu aplikaci shazovat, na druhou stranu se pravděpodobně jedná o hrubou chybu při návrhu aplikace, která by se na produkční server neměla dostat.

Ve speciálních případech, kdy s tím počítám, mi nic nebrání použít $httpRequest->isSent(). Vyhazování výjimek vidím jako přidanou hodnotu třídy HttpResponse.

Nechci polemizovat nad tím, jestli to je chyba a jestli se má logovat

Jen že varování mohu teoreticky přehlédnout, a když tam žádné nebude, nemělo by být ani na serveru.

Mě vychází, že je užitečnější odeslat stránku například bez nastavené expirace jakou jsem zamýšlel, než odeslat stránku chybovou.

Co by ale udělalo poslat obrázek jako text/html? Takže by to možná znamenalo vyjmenovat hlavičky, u kterých to vadí.

Nejsem schopen dodat nic, co bys nevěděl, a obě řešení mají své výhody i nevýhody. Udělej, jak myslíš, za zkoušku by to stálo.

Možná by stálo za to zvážit nějaký parametr $need, jako má třeba metoda getComponent(), když nenajde komponentu a $need je false, tak mi prostě vrátí null a já si to můžu otestovat a řešit; nebo si $need nastavím na true a pak to vyhazuje výjimku.

Určitě bych tam dal možnost ty výjimky umlčet, když vím, že nenastavení určité hlavičky mě nijak neomezí, naopak u těch, které jsou pro mně důležité, ať klidně aplikace spadne, když se je nepodaří odeslat.

PetrP napsal(a):

m0t3jl napsal(a):

Určitě bych tam dal možnost ty výjimky umlčet, když vím, že nenastavení určité hlavičky mě nijak neomezí, naopak u těch, které jsou pro mně důležité, ať klidně aplikace spadne, když se je nepodaří odeslat.

Umlčet si jí můžu tak jako tak

try
	$httpResponse->setHeader('X-Powered-By', 'Nette Framework');
catch (InvalidStateException $e)
	// případně ošetření

pmg napsal(a):

Co by ale udělalo poslat obrázek jako text/html? Takže by to možná znamenalo vyjmenovat hlavičky, u kterých to vadí.

Když je ten obrázek volanej jako <img src="..."> tak to většina prohlížečů zkousne.

David Grudl napsal(a):

Nechci polemizovat nad tím, jestli to je chyba a jestli se má logovat – chyba návrhu aplikace to rozhodně je, jde o to, zda je vhodné na ni reagovat shozením do error presenteru nebo ji jen zalogovat jako E_WARNING.

Během psaní téhle odpovědi jsem třikrát změnil názor jestli Exception nebo E_USER_WARNING, rozhodnutí bych nechal na poslední sobotu ;] uvidíš to jasněji po ctvrtém pivu.

Jde o to, že když ti nevadí, že se ta hlavička nenastaví, tak vstup do catch sekce produkuje docela velkou (a hlavně v takovou chvíli zbytečnou) režiji; testování návratové hodnoty funkce na true/false je daleko rychlejší ;).

Když vím, že mi vyhození té výjimky (aka nenastavení hlavičky) bude vadit, tak klidně do toho catch blobku skočím, protože už se prostě stalo něco špatného a zpomalení pro uživatele je neodvratné :D.

Lhal bych, kdybych řekl, že jsem to testoval, určitě je ta režie daleko vyšší než testování na false nebo na null ;).

PetrP napsal(a):

Během psaní téhle odpovědi jsem třikrát změnil názor jestli Exception nebo E_USER_WARNING, rozhodnutí bych nechal na poslední sobotu ;] uvidíš to jasněji po ctvrtém pivu.

A vyřešili jsme to nějak? ;-)

Takže s odstupem měsíce… mám stále stejný názor, vyhazování výjimek bych zrušil.